Friday, May 9, 2014

7 facts related to OAuth and OpenID flaw


Of which 3 of them relate to development/implementaion and one relates to users (Social Engineering).

NOTE: 
The flaw highlighted by Wang -- which isn't new -- doesn't exist in OAuth 2 or OpenID, but rather in how some businesses have implemented those and other standards

Something I learnt:
Many web applications that rely on third-party authentication use what's called an implicit flow. That involves giving a browser client an access token after the user gives that client access.

he recommends that developers use the more complex "code flow" approach, which involves additional API calls to further verify the authenticity of the client, and which becomes essential for ensuring security when clients maintain any type of server-side state. It also adds the ability to refresh the token and provide offline access.



According to the article:-

1. At risk: open redirects
The primary problem pertains to the use of open redirects, which redirect HTTP requests. "There have been open redirectors for as long as there's been HTML," 


2. Developers, sites, don't follow security recommendations
Many sites and developers don't follow the security mitigations recommended by the standards. Facebook, for example, allows developers to use whitelisting to restrict the range of sites to which incoming open-redirect requests can be redirected, which would block related exploits. But Facebook made it an optional feature.


3. ESPN abuse highlights attack seriousness
Wang demonstrated that precise flaw in a YouTube clip, showing how an open redirector located on the ESPN website -- which allowed users to authenticate using Facebook Connect -- could be abused. Notably, the open redirector redirected to any site specified in a URL parameter, and also passed the query string parameters to the receiving site.


4. Beware social engineering angle
Another way open redirectors can be abused is to send users to malicious sites. If that happened, though, Symantec's Narang said the site would have to trick the user into allowing their third-party credentials -- for example, from Facebook or Google -- to be used to log into the site. "So it involves social engineering -- that part needs to be clear," he pointed out.


5. Developers: know your state
One way to mitigate related vulnerabilities is to restrict the URLs to which the redirector will redirect. "It's always best, if you can, to do exact URI redirect matching,"

6. After coordinated disclosure, some sites fixed
Wang said he notified all businesses that he's listed as having vulnerable implementations of OAuth 2 or OpenID prior to making his public announcement earlier this month. "I found this vulnerability at the beginning of February and I have reported it to related companies," he said.

7. Fixing insecure implementations will take time
Some affected sites have already put related fixes in place. On March 13, for example -- evidently after receiving Wang's vulnerability report -- LinkedIn told developers they would have one month to register their OAuth 2 redirect URLs. "If you do not take the steps noted above by April 11, 2014, requests to authorize new members or refresh tokens will fail. We will display an error message and not redirect the member to your application," LinkedIn said.

But not every site appears willing to practice that type of tough love. Some are opting for more phased transitions. "Facebook making any type of change, because they have such a large client/developer base, if they turned on maximum security, all the people who wrote clients [that assume] weak security, they're going to break," Bradley said.


The link below has more information:-


No comments:

Post a Comment