Showing posts with label XSS. Show all posts
Showing posts with label XSS. Show all posts

Monday, May 10, 2021

How to Detect Cross-Site Scripting (XSS)

Cross Site Scripting (XSS) Attacks

Cross Site Scripting Attacks (XSS) are a types of injection attack in which malicious codes are injected into website. These websites, otherwise, looks benign and trusted. Hackers have discovered numerous and ingenious methods for injecting malicious code into websites via Common Gateway Interface (CGI) scripts, web server software vulnerabilities, SQL injection attacks, frame exploitation, DNS redirects, cookie hijacks, and many other forms of attack.

In XSS attacks, an attacker sends a malicious code using a web application to an unsuspecting user, generally in the form of specially crafted links. Crafted code will get executed when the user visit the link, and then harm is done. Change in behavior or appearance of the website, action performed on behalf of the user, or stealing personal information are simple examples of successful XSS attack.
XSS can, thus, be thought of as a security bug or flaw that affects websites. A flaw that can occur anywhere a web application accepts input from a user and generates output without proper validation.

A successful XSS attack can result in identity theft, credential theft, data theft, financial losses, or the planting of remote-control software on visiting clients.

Thus, 
  • XSS attacks enable an attacker to inject their malicious code (in client-side scripting languages, such as JavaScript) into vulnerable web pages. 
  • When an unsuspecting user visits the infected page, the malicious code executes on the victim’s browser and may lead to stolen cookies, hijacked sessions, malware execution, or bypassed access control, or aid in exploiting browser vulnerabilities. 
There are three different XSS vulnerabilities:
  1. Nonpersistent (reflected) XSS vulnerabilities: Attacker tricks the victim into processing a URL programmed with a rogue script to steal the victim’s sensitive information (cookie, session ID, etc.). The principle behind this attack lies in exploiting the lack of proper input or output validation on dynamic websites.
  2. Persistent (stored or second-order) XSS vulnerabilities: It is targeted at websites that allow users to input data that is stored in a database or any other such location, e.g., forums, message boards, guest books, etc. The attacker posts some text that contains some malicious JavaScript, and when other users later view the posts, their browsers render the page and execute the attacker’s JavaScript.
  3. DOM (Document Object Model or local XSS)–based XSS vulnerabilities: DOM is the standard structure layout to represent HTML and XML documents in the browser. In such attacks the document components such as form fields and cookies can be referenced through JavaScript. The attacker uses the DOM environment to modify the original client-side JavaScript. This causes the victim’s browser to execute the resulting abusive JavaScript code.
Where should you collect logs from?
Web Server, Web Application Firewall, IDS/IPS logs
How to detect using SIEM?
There are certain common code that needs to be injected for the attack to be successful.  <script>  tag is present in log whenever XSS attack is seen in URL field.

URL can be have any of value in this list 

[*<script>*, *%3c%73%63%72%69%70%74%3e*, *%3cscript%3e*]

How to defend against XSS?

As an administrator you can do following
  • maintain a patched web server, 
  • use web application firewalls, 
  • operate a host-based intrusion detection system (HIDS), 
  • audit for suspicious activity, and, 
  • most important, performing server-side input validation for length, malicious content, and metacharacter filtering. 
As a web user you can do following
  • keep your system patched, 
  • run antivirus software, and 
  • avoid non-mainstream websites. 
There are add-ons for some web browsers, such as NoScript for Firefox and uBlock Origin for Chrome, that allow only scripts of your choosing to be executed.
 
For web application and penetration testing, there are different vendors out there that provide such services. Security for Everyone (S4E) is one such vendor which provide various professional services.

Sunday, June 14, 2020

Hacker101 CTF: Micro-CMS v1 Part 2

Now moving on to the next challenge.


Here we have something to click on :D. First what I did was clicked on all


Testing had some static text, while Markdown Test included one button but nothing was working there. Next, in create page there was some form we can fill up. This looks exciting, because form means we can inject some XSS script. But this needs to be tested, so what I did was, created a page with title "Just for Fun" and description "This text is written just for fun." and the effect was? My text was stored there and home page had indexed my title as well.


This indicates that store-XSS could be possible. So let's create a new page and include XSS thing in the title.
XSS Test<script>alert(1);</script>

The page will be created. Now if you go to your home page Voila! there is a flag.


To get the flag you can also edit the page you created last time to include script like above.


Hacker101 CTF: Micro-CMS v1 Part 4

Now the last part of this exercise, finding the fourth flag.

Until now, we've tried manipulating URL and the Title. We have not yet touched the body part in edit page. My guess is, this is the place where final flag should be. For this, I edited Markdown Test. There is "some button" where user definitely will click at first glance itself. Due to this reason, if we can manipulate this button to store script, it would be ideal for us.

Also, edit page clearly shows that "Markdown is supported, but scripts are not". This means we can make use of makdown in the body part to manipulate button. Let's look for different options to change the button behavior.

Doing some random testing and many hit-and-trial, I finally landed in this script

<button onclick=alert('Scripted')>Some Button</button>

Then hit save. Click on Some Button now. Alert message is generated so XSS attempt is successful. Even with this flag is not seen in the screen. But the good news is we already have the flag. 
I have developer tools always open and each time I make any change, I make sure to check on all elements, just in case there is a flag. And this time it was!