Cross Site Scripting - XSS - Saldırı Amaçlı Bir Girdi Verilir

Giriş
XSS aslında bir anlamda SQL Injection'a benziyor. Amaç saldırganın saldırı amaçlı bir script'i girdi olarak vermesi. Açıklaması şöyle

XSS is a vulnerability where an attacker can inject malicious code (usually JavaScript) into a web page, potentially allowing them to steal sensitive data or perform actions on behalf of the user. This vulnerability can be mitigated by sanitizing user input and encoding output to prevent the execution of malicious scripts.

Bir başka açıklama şöyle. 

Anatomy of an XSS attack
XSS happens whenever an attacker can execute malicious scripts on a victim’s browser.

Applications often use user input to construct web pages. For example, a site might have a search functionality where the user can input a search term, and the search results page will include the term at the top of the results page. If a user searches “abc”, the source code for that page might look like this:

<h2>You searched for abc; here are the results!</h2>

But what if that application cannot tell the difference between user input and the legitimate code that makes up the original web page?

Attackers might be able to submit executable scripts and get that script embedded on a victim’s webpage. These malicious scripts can be used to steal cookies, leak personal information, change site contents, or redirect the user to a malicious site.

3 çeşit XSS saldırısı var. Bunlardan Stored XSS ve ReflectedXSS bağlantılı. 

- Stored XSS güvenli olmayan bir kaynaktan gelen bilginin saklanması

- Reflected XSS ise bu saklanan bilginin bir başka kullanıcıya gönderilmesi anlamına gelir. Açıklaması şöyle.

An XSS vulnerability usually consists of two components: A backend which reflects user-provided strings without filtering them and a frontend which puts that input into a HTML document without filtering it.

1. Reflected XSS - Kullanıcı Girdisince Zararlı Script Vardır

Açıklaması şöyle

A reflected XSS, or reflected cross site scripting, is the process of adding malicious scripts that is activated through a link. The request then sends the user to somewhere else.

For example, a reflected XSS can be embedded to blend in with the rest of the site in a user comment section. The user may click on it and end up going to a 3rd party site and then redirected back to the original site.

Whilst at the 3rd party, malicious activities such as cookie or session stealing may occur. Although it is hard to monitor reflected XSS, spam filters on links submitted can help reduce the frequency.

Örnek

Şöyle yaparız

For example, if the application also allows users to search via URLs:
https://example.com/search?q=abc

If an attacker can trick victims into visiting this URL:

https://example.com/search?q=<script> some malicious script</script>

The script in the URL will become embedded in the page the victim is visiting, making the victim’s browser run the JS code contained within the <script> tags. This is called a “reflected XSS” attack.

<h2>You searched for <script> some malicious script</script>; here are the results!</h2>

2. Stored XSS - Veri tabanına Zararlı Scrip Koyulur

Açıklaması şöyle

A stored XSS, or persistent XSS attack takes place when an attacker injects a script into the content of a website or app. Unlike reflected XSS where third party links are embedded, store XSS is more dangerous in that it doesn’t require the user to interact with it.

Açıklaması şöyle

During a stored XSS attack, the attacker places the malicious script into a database before it gets returned to the victim. Let’s say that example.com also allows users to post status updates for others to see. An attacker can post this status update:

POST /status/updatestatus=<script> some malicious script </script>

This malicious script will become embedded on the attacker’s profile page, attacking anyone who visits the attacker’s profile page.

3.  DOM Based XSS 

Açıklama şöyle

DOM Based XSS can arise when the application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

Açıklaması şöyle

Finally, DOM-based XSS is similar to reflected XSS, except that in DOM-based XSS, the user input never leaves the user’s browser. Since the malicious input is never sent to the server, this type of XSS is harder to detect and prevent.

As in reflected XSS, attackers submit DOM-based XSS payloads via the victim’s user input. Unlike reflected XSS, a DOM-based XSS script doesn’t require server involvement, because it executes when user input modifies the source code of the page in the browser directly. Say a website allows the user to change their locale by submitting it via a URL parameter:


https://example.com?locale=north+america

The URL parameter isn’t submitted to the server. Instead, it’s used to change the language of the webpage by a client-side script of the application. But if the website doesn’t validate the user-submitted parameter, an attacker can trick victims into visiting a URL like this one:


https://example.com?locale=<script> some malicious script </script>

The site will embed the payload on the user’s web page, and the victim’s browser will execute the malicious script.

StringEscapeUtils

StringEscapeUtils sınıfı kullanılarak bazı tedbirler alınabilir.

Http Cevabında X-XSS-Protection  Alanı

Açıklaması şöyle

Some browsers have built in support for filtering out reflected XSS attacks. This is by no means full proof, but does assist in XSS protection. Below HTTP response header just ensures it is enabled and instructs the browser to block when a XSS attack is detected.

X-XSS-Protection: 1; mode=block

Spring security automatically adds this header by default. We do not need to make any changes in our application to get this.

Http Cevabında Content-Security-Policy Alanı

Açıklaması şöyle

A Content Security Policy(CSP) compatible browser will only execute scripts loaded in source files received from our “allow” listed domains, ignoring all other scripts such as inline scripts.

To enable this feature, the browser needs to receive the below HTTP response header

Content-Security-Policy: script-src 'self'

We can accomplish by adding below line in our Spring Boot app

headers().contentSecurityPolicy("script-src 'self'")

Sunucuya JavaScript Gönderilmesi

Örnek
Şöyle yaparız

http://test.com/%3Cscript%3Ealert(%E2%80%98XSS%E2%80%99)%3C/script%3E

Örnek

Elimizde şöyle bir kod olsunn ve bir post isteği gönderilim

@PostMapping("/books")
public void createBook(@RequestBody Book book) {
  bookService.save(book);
}

POST /books
{
  "id" : 3,
  "name" : "Harry Potter",
  "type" : "<script>alert(document.cookie)</script>"
}

Get isteği gönderilince bu javascript çalıştırılabilir.

Tarayıcıya JavaScript Gönderilmesi
Açıklaması şöyle.

In XSS, an attacker can maliciously inject Javascript into an application running on the victim’s browser. The injected code reads and transmits auth tokens to the attacker .

This can be prevented fairly easily by using HttpOnly or Secure cookies to store auth tokens. Do not use localStorage to store auth tokens, as they are accessible by javascript.

Yapılabilecek şeylerin listesi şöyle.

Ad-Jacking - If you manage to get stored XSS on a website, just inject your ads in it to make money ;)



Click-Jacking - You can create a hidden overlay on a page to hijack clicks of the victim to perform malicious actions.

Session Hijacking - HTTP cookies can be accessed by JavaScript if the HTTP ONLY flag is not present in the cookies.

Content Spoofing - JavaScript has full access to client side code of a web app and hence you can use it show/modify desired content.

Credential Harvesting - The most fun part. You can use a fancy popup to harvest credentials. WiFi firmware has been updated, re-enter your credentials to authenticate. Forced Downloads - So the victim isn’t downloading your malicious flash player from absolutely-safe.com? Don’t worry, you will have more luck trying to force a download from the trusted website your victim is visiting.

Crypto Mining - Yes, you can use the victim’s CPU to mine some bitcoin for you!

Bypassing CSRF protection - You can make POST requests with JavaScript, you can collect and submit a CSRF token with JavaScript, what else do you need?

Keylogging - You know what this is.

Recording Audio - It requires authorization from the user but you access victim’s microphone. Thanks to HTML5 and JavaScript.

Taking pictures - It requires authorization from the user but you access victim’s webcam. Thanks to HTML5 and JavaScript.

Geo-location - It requires authorization from the user but you access victim’s Geo-location. Thanks to HTML5 and JavaScript. Works better with devices with GPS.

Stealing HTML5 web storage data - HTML5 introduced a new feature, web storage. Now a website can store data in the browser for later use and of course, JavaScript can access that storage via window.localStorage() and window.webStorage() Browser & System

Fingerprinting - JavaScript makes it a piece of cake to find your browser name, version, installed plugins and their versions, your operating system, architecture, system time, language and screen resolution.

Network Scanning - Victim’s browser can be abused to scan ports and hosts with JavaScript.

Crashing Browsers - Yes! You can crash browser with flooding them with….stuff.

Stealing Information - Grab information from the webpage and send it to your server. Simple!

Redirecting - You can use javascript to redirect users to a webpage of your choice.

Tabnapping - Just a fancy version of redirection. For example, if no keyboard or mouse events have been received for more than a minute, it could mean that the user is afk and you can sneakily replace the current webpage with a fake one.

Capturing Screenshots - Thanks to HTML5 again, now you can take screenshot of a webpage. Blind XSS detection tools have been doing this before it was cool.

Perform Actions - You are controlling the browser,

Örnek
Json tipinden cevaplar XSS saldırısına uygun değildir. Elimizde şöyle bir cevap olsun

curl -i  'https://myservice.example.com/<script>alert(1)</script>'
HTTP/2 401
server: nginx
date: Tue, 19 May 2020 15:02:20 GMT
content-type: application/json;charset=UTF-8
content-length: 167
strict-transport-security: max-age=31536000 ; includeSubDomains
www-authenticate: Basic realm="Spring"

{"..."}%

Açıklaması şöyle.

This isn't vulnerable to XSS since the Content-Type is set to application/json and thus no Javascript will be executed by all major modern browsers. If you do some fancy Javascript stuff with the JSON response, it could become a DOM XSS

Örnek

Elimizde şöyle bir URL olsun.

http://www.example.com/apage?filename=malicious.js

Kullanıcılar en çok bir linke tıklayarak bir tür saldırılara maruz kalıyorlar.

Örnek - Source URL
Elimizde arama için kullanılan bir URL olsun. Bu URL'ye kendi script'imizi gönderebiliriz. Şöyle yaparız.

https://www.example.com/search?data=<script src="..."></script>

Örnek - Source URL
Elimizde şöyle bir HTML olsun

<html>
<body>
<script>
  url = new URLSearchParams(location.search);
  x = url.get('x');
  document.write(x);
</script>
</body>
</html>

Bu URL'ye kendi script'imizi gönderebiliriz. Şöyle yaparız

http://example.com/test.html?x=<script>alert(1)</script>

Örnek
Elimizde şöyle bir kod olsun. Bu kodda isim <travis> olduğu için render edilmez.

<html>
  <head><title>HI</title></head>
  <body>
    <h1>WEBSITE</h1>
     Hey my name is <travis>.
  </body>
</html>

HTTP parameter pollution attack
Açıklaması şöyle.

This isn't a regular problem in modern web applications because parameter parsing is done by the framework usually, in (modern versions of) php for example, $_GET["postuid"] would contain the same value for both code fragments, making a HTTP PP attack useless.

HTTP PP used to be a big problem (and still is, whenever this is the case) when parameters are parsed "by hand", i.e. on the application logic layer. That opens the door for different people implementing this parsing differently.

Örnek
Beklenen URL şöyle olsun

https://security.stackexchange.com/editpost/?postuid=19348

Saldırı için şöyle bir URL gönderelim.

https://security.stackexchange.com/editpost/?postuid=19348&postuid=1