Day 61/100 Hack and Improvement
Day 61 comes with Reflected XSS, Client Side Template injection, and Covering a little on OAuth!
Reflected XSS and Client Side Template injection
From Rajesh Ranjan. Here is the report for the reflected xss, and this is for the 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.
- Common
https://yourtweetreader.com/callback?redirectUrl=https://evil.com
- Path Traversal
https://yourtweetreader.com/callback/../redirect?url=https://evil.com
- Weak Redirect Regex
https://yourtweetreader.com.evil.com
- HTML Injection and stealing tokens via referer header:
https://yourtweetreader.com/callback/home/attackerimg.jpg
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:
https://yourtweetreader.com?code=asd91j3jd91j92j1j9d1
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.
Leave a comment