Day 61 comes with Reflected XSS, Client Side Template injection, and Covering a little on OAuth!
Reflected XSS and Client Side Template injection
Covering a little on OAuth
From Sam (CoffeeJunkie). Lately in couple targets I have seen the function related to OAuth at the time to sign in, after completing couple Pentesterlab exercises related to OAuth, I got more curious about it, then started to research more info on how this can be exploitable in different cases. Therefore, I found this this which explains part of the basics. I’m gonna be handling some of the basics today in order to learn and have a clear path the next time I approach an app with OAuth implementation.
What is OAuth?
We’ll be talking about OAuth 2.0 which basically is essence, it provides developers an authorization mechanism to allow the web application to access data or perfom actions agains an account in other application. Simply, that’s why some websites has the option “Sign in with Google” in order to access data or perfom actions agains an account in other application. If you want to undestand how OAuth authentication flow works, I strongly recommend visiting this article.
Common vulnerabilities and findings
Weak redirect_uri configuration
This is usually one of the most common things that people would be aware of at the time to do the OAuth implementation. The reason why people are aware is because of its sensitive data such as
code which is appended to the URL, and
redirect_uri which can be redirected to other attacker and potentially takeover a victim’s account.
In order to explouit this, it depends purely on the authorization server. Sometimes it will exact only the same
redirect_uri path specified by the client, but others will accept anything under the same domain or subdirectory of the
redirect_uri . These are the common bypasses for this type of weakness.
- Path Traversal
- Weak Redirect Regex
- HTML Injection and stealing tokens via referer header:
Improper handling of state parameter
Usually, this is a common issue in OAuth implementations. In some cases, the
state parameter is completely ommited or used in the wrong way. If a state parameter is nonexistent, or a static value that never changes, the OAuth flow will very likely be vulnerable to CSRF. In order to exploit this, the attacker would have to go through the authorization server and stop the process after authorizing, the request would look like:
Once you receive the request, you can drop it due to the code is usually one time use. You can send the URL from above to a logged in user and it will add your account to their account. In this way it’s possible to perform an account takeover.