March 2020
All about hacking and cyber security I present ways of hacking over all platforms also trending news & info bugbounty tutorial for penetration testers

Cross-Site Scripting (XSS)

Cross site scripting (XSS) guide
Cross-Site Scripting (XSS) is commonly found a vulnerability in many client-side websites and can be easily found sometimes and sometimes takes lots of effort to find its presence. in this article, I will show you practically what cross-site scripting (XSS) is..?, how to find XSS..?, how to prevent XSS, and much more to know about Cross-site scripting.


    •  What is cross-site scripting?

    Cross-site scripting is commonly known as XSS which is a web-based security vulnerability that allows an attacker to interfere between vulnerable web application and user.
    If a web application is vulnerable with cross-site scripting (XSS) and user using it with privilege access or even normally using data and connecting with a web application. an attacker can exploit a cross-site scripting (XSS) to masquerade as a victim user and perform and access all user's data and also can get full control over applications functions and all the data.
    so you can understand how dangerous this vulnerability can be if exploited.

    we will know more about cross-site scripting (XSS) with its types.

    Types of cross-site scripting attacks (XSS Attacks)

    1. Reflected Cross-Site Scripting ( Reflected XSS)
    2. Stored Cross-Site Scripting ( Stored XSS)
    3. DOM-based Cross-site scripting ( DOM XSS)
     there are three Cross-Site Scripting types that are present we will see through them one by one with XSS example

    1. Reflected Cross-Site Scripting ( Reflected XSS Attack)

     Reflected XSS can arrive when a vulnerable web application receives scripts or data from the user and present it back to web application response in unsafe ways. As the word suggests Reflected, the input data or script can reflect back to the application without a change in it.

    for better understanding, I am using DVWA for practical use.
    If you don't know how to install DVWA check out

    • Reflected XSS in DVWA (XSS example)

    As we can see in DVWA reflected cross-site scripting (XSS) is functional with parameter input fields such as search bar and other input fields shown in the image.

    Reflected cross site scripting

    here in DVWA 'what's your name?' is parameter field is present so we can use lots of payloads to test if it's vulnerable or not but first we will be using


    payloads are scripts used in XSS which can be modified or used as per application is validating our input. using the above script shows the following pop-up.

    Reflected cross site scripting using DVWA

    that script simply says web application to alert 'Hello'. and as you can see in the application it popped-up 'Hello' without validating anything.

    this script won't work with all web applications because each has different factors that are validating the input and present that validated input via a web application.
    you will get it in the next example.

    XSS in input Validating application

    In this example, we will be going to see another example of Reflected XSS.

    we have the same screen in DVWA as before but this time it's different let me show you how.

    As you can see we injected the same payload in there but instead of pop up we got our validated script back.
    As shown in the image our web application validating <script> tags this time.
    sometimes it's difficult to find what application is validating because it totally depends on the developer to set validations.
    to find it, simply keep trying different payloads or modify payloads with our needs.
    Don't worry about XSS payloads I will link it in the end.
    Now get back to this Reflected XSS, we need to execute our script without or with getting validated right..?
    so we will nest this script tag with another. means we will insert one more script tag in there so if one gets validated by the application then another will be there and execute that script.
    modify that script as nested.

    <scr<script>ipt>alert('XSS vulnerable')</script>

    this will clear you what nested really is so let's see what happens..

    Reflected cross site scripting ( reflected xss dvwa)

    we got a pop-up this time so we can say this web application is vulnerable to XSS  but validating <script> tag. so our approach to further exploitation will be using payloads without <script> tag or nest the tag as we did above.
     so this is how you can get an idea about how web application validated or process inputs determine which type of payload is required and the impact of that vulnerability.

    2. Stored Cross-Site Scripting ( Stored XSS)

    Stored XSS basically is, an attacker can inject malicious script or payload in parameter input like a comment field or review application field.
    but the catch here is as you can see name Stored, means that the script or payload gets stored in the application execute every time the user visits that page.
    The user is fully compromised if an attacker can control scripts that can be executed in the victim's browser. which makes it more dangerous than reflected XSS because the attacker can get full control over the user's data and access.

    we will know more about stored XSS using an example.

    • Stored XSS in DVWA ( Stored XSS example)

    first, we can see a parameterized input field in there this sign in for guest book is the place where we will be using our payloads.

    stored XSS dvwa

    In this example, we will be using payload.

    <a onmouseover="alert(1)">test</a>

    this payload pop up an alert when the mouse cursor is hovered over on the text simple and effective to trigger stored XSS.
    just sign in using this payload and you will see an entry named test is made up there. as we hover over the mouse curser there the pop-up will show like in the image.

    This is one of the methods attackers can inject payload in an application and then it gets stored in a web application without validation and also executes when a user interacts with it.
    as you can see unlike reflected XSS, stored XSS does not need active user interaction. payload stored in a vulnerable web application can execute when the user interacts with that page and the attacker can have full control over the user's session and data which makes stored XSS more dangerous than reflected.

    3. DOM-based cross-site scripting ( DOM XSS)

    In DOM-based cross-site scripting (DOM XSS) attackers can use javascript in web applications using controllable sources this code will further arbitrarily execute in a sink that supports dynamic code execution.
    in this attack, the payload can be bound with query strings and fragment portions of the URL so whenever that URL will be opened by the user payload will execute and all user data and session can be accessible to an attacker.

    • DOM-based cross-site scripting using DVWA (DOM-based XSS example)

    In DOM-based XSS we need to construct an input field which is a URL that can manipulate to sending any javascript to the sink of the web application.

    as in the image above we can construct the URL by simply adding javascript after default=' ' and removing the parameter English given by the web application.
    we will try the same alert javascript.

    in this image I used javascript

    <script>alert('XSS Vulnerable')</script>

    and Web application is given pop-up which means it is vulnerable to DOM-based XSS and this javascript executed arbitrarily.

    this way attackers can construct a link with payload in it and send it to a victim also do this to websites 404 page and other breadcrumbs so the victim can open it and javascript will arbitrarily execute in that page and victims session and data is accessible by an attacker.

    There are 3 types of cross-site scripting (XSS) and these are very common web security vulnerabilities found.

     Impact of cross-site scripting

    impact of XSS can be range from minimal to critical depending on a web application.
    in an application where users are anonymous and public information is the present impact of XSS can be minimal here.
    if the site is storing sensitive data of users then the impact can be serious.
    if an attacker can privilege escalated within the application then he can have full control of the application and this will be critical.

     How to Prevent cross-site scripting

    prevention of XSS attacks can depend on how applications handle user-controlled data and the complexity it.
    prevention of XSS attacks can be done using the following security measures.

    1. By filtering user inputs -  as based on valid input user input should be validated correctly and strictly using input filters. expected input only allows to processed further and unnecessary input such as scripts and payload can be validated to some extend.
    this you can see in the example above, where we used nested script.

    2. Output data needs to be encoded - output data that is generated by user-controllable data can be encoded first before showing it on web pages. data encoding can make it very difficult for an attacker to find the output because it's encoded. also using a different encoding such as javascript, HTML, CSS, URL can make it tough to get output from web application.

    3. response headers -  response headers such as content-type and x-content-type-options can be used to prevent  XSS in HTTP responses which can be interpreted by the browser. it simply disables HTML or javascript contains in response.

    cross-site scripting (XSS) cheat sheet- 

    this XSS cheat sheet contains tons of payloads you can use while testing cross-site scripting. also, modified payloads can be used taking inspiration from this XSS cheat sheet.

    All about hacking and cyber security I present ways of hacking over all platforms also trending news & info bugbounty tutorial for penetration testers

    DVWA in Kali Linux Using Xampp

     To use DVWA in Kali Linux which is a vulnerable web application for testing purposes we will be using the Xammp server to configure our MySQL server and Apache server to host dvwa web application. which is the easiest way to install Dvwa in Kali Linux.

    first of all, we need to install files we needed

    1. Damn Vulnerable Web Application (DVWA)  -->  Download 

      2. XAMPP --> Download

      for DVWA simply click on download and it will open the site URL and Download it from there.

      DVWA Download
      DVWA Download

      For Downloading XAMPP open the link clicking Download and scroll down to find a file for Linux. you can also download for windows and MAC from here.

      Downloading XAMPP

      Downloading XAMPP

      After downloading XMAPP go to your downloads and right-click on the installer and in permissions allow it to run as a program.


      now click on the XAMPP installer and complete the installation process.

      in between, it will tell you where is XAMPP directory is so keep it in mind.

      usually, it's in 


       now  extract dvwa file we Downloaded and copy it, 

      paste  dvwa file in htdocs


      now open that dvwa file named DVWA-master in default you can name it whatever you want, 

      open config folder,

      you will see there

      now copy it and paste it there so if we did mistakes in the config we can still have an original version of it,

      and rename the original file to 

      simply remove .dist from there,

      DVWA config

      now open file and find their password and remove it from there, keep it blank.

      DVWA config

       now to ready to go toward XAMPP , to open XAMPP manager we need to go in /opt/lampp where we can find


      Click on it and XAMPP will open. it will show welcome

      simply go in manage server, and start MySQL database and apache webserver


      all set, now go to browse and type localhost in the URL section, it will show the XAMPP page first, now we need to type 


      and it will open the DVWA webpage now scroll down and click on create a database and then on the next page, 

      username- admin

      password- password

      after hitting enter you are in DVWA and have all of the functions ready to use its default difficulty is impossible to make it according to your testing.




      This is the easiest way to install vulnerable web applications like DVWA but you can host other vulnerable web applications also in XAMPP Ex. BWAPP

      practicing hacking in a vulnerable web application is a must for all beginner hackers.

      so get to work with it,


      Happy Hacking...