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.

1. Common https://yourtweetreader.com/callback?redirectUrl=https://evil.com
2. Path Traversal https://yourtweetreader.com/callback/../redirect?url=https://evil.com
3. Weak Redirect Regex https://yourtweetreader.com.evil.com
4. 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.