Security breaches on Web Application
Security Breaches on Web Application
Basically we have several types of security breaches on Web application
1. Session Fixation
2. CSRF
3. Click Jacking
Session Fixation
Session fixation, by most definitions, is a subclass of session hijacking. The most common basic flow is:
Step 1. Attacker gets a valid session ID from an application
Step 2. Attacker forces the victim to use that same session ID
Step 3. Attacker now knows the session ID that the victim is using and can gain access to the victim’s account
Step 2, which requires forcing the session ID on the victim, is the only real work the attacker needs to do. And even this action on the attacker’s part is often performed by simply sending the victim a link to a website with the session ID attached to the URL.
We need to make sure about
Fortunately, resolving session fixation is usually fairly simple. The basic advice is:
Invalidate the user session once a successful login has occurred.
The usual basic flow to handle session fixation prevention looks like:
1. User enters correct credentials
2. System successfully authenticates user
3. Any existing session information that needs to be retained is moved to temporary location
4. Session is invalidated (HttpSession#invalidate())
5. New session is created (new session ID)
6. Any temporary data is restored to new session
7. User goes to successful login landing page using new session ID
CSRF (Cross Site Request Forgery)
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.
CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing.
If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
For Example
<!DOCTYPE HTML SYSTEM "about:legacy-compat">
<html lang="en">
<head>
<title>Cross Site Request Forgery Demo</title>
</head>
<body>
<form id="command" action="http://localhost:8080/sample/100" method="post">
<input type="hidden" name="_method" value="delete">
<input value="Win Money!" type="submit">
</form>
</body>
</html>
Note : We can disable crosssite request forgeries by disabling through application. like csrf.disable() and headers.disable() on HTTP request in Spring Security.
Click Jacking
A clickjack takes the form of embedded code or a script that can execute without the user's knowledge, such as clicking on a button that appears to perform another function.
For Example
<!DOCTYPE HTML SYSTEM "about:legacy-compat">
<html lang="en">
<head>
<title>Clickjacking Demo</title>
<style type="text/css">
#message-content
{ // Content css props of the Page
}
#message-content iframe
{ // css props of the page
}
</style>
</head>
<body>
<form action="#" method="post">
<input id="attack" type="submit" value="Win Money!"/>
</form>
<div id="message-content">
<iframe src="http://localhost:8080/sample/"></iframe>
</div>
</body>
</html>
If we can see both the text "Win Money!" at the top of the page and your target web page successfully loaded into the frame, then your site is vulnerable and has no type of protection against Clickjacking attacks. Now you can directly create a "proof of concept" to demonstrate that an attacker could exploit this vulnerability.
We can avoid this by
Methods to protect a web page from clickjacking can be divided in two macro-categories:
- Client side protection: Frame Busting
- Server side protection: X-Frame-Options
Comments
Post a Comment