My review on “Exploiting and Securing Vulnerabilities in Java Applications” in Coursera
My job recently has to build a solution for user management and protecting OWASP risks is important. Then, I want to know more about how my application can be attacked to have deeper insight.
I decdie to take the course from Coursera: Exploiting and Securing Vulnerabilities in Java Applications
https://www.coursera.org/learn/exploiting-securing-vulnerabilities-java-applications.
This course ease my reading of OWASP cheetsheets. Before they are superficial to me and now I see how the attack can happen.
The followings are my detail review:
The topics cover
- XSS — Client
- Injection — Server
- Authentication
based on WebGoat, the project that OWASP develops for exercising attack and defense.
For me the XSS Client is useful to know Frontend attack. The injection part is simple and by using the proper library nothing can go wrong in my experience. The useful tool I learn in the injection part is how to setup Burp
which is a free tool to hack your application. You can intercept the call, change the params easily and send the request to the server.
The most useful part is Authentication. It covers authentication bypass and JWT. The exercise can bring your understanding to another level.
The attack is also provided with 1 or 2 examples that happened in the real world in the past, to give you deeper impression.
XSS Client:
- Stored XSS
BeEF - The Browser Exploitation Framework Project
Case
- MySpace Worm Explanation
- Hackers still exploiting eBay's stored XSS vulnerabilities in 2017 | Netcraft News
and the solution is to use the encoder.
Authentication
Authentication bypass
- Example Paypal 2FA Bypass
- Fail closed and not Fail open
JWT
- CyberChef
- JWT cracking by using common words
- https://github.com/first20hours/google-10000-english
Refresh token
- Regardless of the chosen solution you should store enough information on the server side to validate whether the user is still trusted. You can think of many things, like store the ip address, keep track of how many times the refresh token is used (using the refresh token multiple times in the valid time window of the access token might indicate strange behavior, you can revoke all the tokens an let the user authenticate again).
- Also keep track of which access token belonged to which refresh token otherwise an attacker might be able to get a new access token for a different user with the refresh token of the attacker (see JWT Refresh Token Manipulation for a nice write up about how this attack works).
- Also a good thing to check for is the ip address or geolocation of the user. If you need to give out a new token check whether the location is still the same if not revoke all the tokens and let the user authenticate again.
- In the case the refresh tokens are stored for validation it is important to protect these tokens as well (at least use a hash function to store them in your database).
JWT a good idea?
- There are a lot of resources available which question the usecase for using JWT token for client to server authentication with regards to cookies. The best place to use a JWT token is between server to server communication. In a normal web application you are better of using plain old cookies. See for more information:
- stop-using-jwt-for-sessions
- stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work
- flowchart
Here I also provide some solutions when you get stuck to solve the exercises from WebGoat
