One outcome of this attack is website defacing or changing the way your website looks. This may sound familiar because you might have heard this in recent reports when hacktivists attack government websites. Using code injection the attacker can tell the back-end what the front UI will look like and it will obediently follow the attacker, for the website has no idea what is wrong to begin with.
Another headache this attack can produce is SQL injections that will lead to stealing sensitive data stored in the back end of the website. The phrase “stealing sensitive data “’s really a big deal for everybody and we all know this doesn’t sound very nice. Nobody wants to be read like an open book in public without them knowing, that of course if there’s no data to hide to begin with.
Attack Demo 1
Doing an attack by inserting the script “print “<script>alert(“LOLOLOL”);</script>”” on a search input box on a demo site https://demo.pandoralabs.net, we can see in the screenshot Attack Demo 1 that it triggered an alert. The resulting action had a URL like this:
Looking at the event information panel can help us verify it this is indeed our attack that triggered.
Checking the destination IP, the sensor ‘demo.pandoralabs.net’, and the affected parameters, this will help us verify the event. The affected parameter GET.s=print “” has the script on the Hex payload detail in the event information. With this we have proved that this event is our attack.
Additional Payload Details
Looking at Additional Payload Details picture, the signatures only confirms our claim that this is our cross-site scripting attack. It explicitly says here that this event is under the basic XSS signature. This also to show the rest of the payload details that is not clearly seen from the previous picture.
Attack Demo 2
Another way to attack it is by placing the script in the URL like this:
This will result in the attack seen in the picture Attack Demo 2 above. We can also see here that the GET is the affected parameter here and they have the same set of signatures from Attack Demo 1.
Looking and addressing these level of these alerts, high and emergency levels, we would block these source IP’s from accessing the web application to prevent even more possible damage to that application. After blocking we would inform concerned parties that an attacker is trying to compromise your web application and advise them to do some necessary changes to their configurations or their codes to prevent these kinds of attacks. If they already have a way to prevent or counter this attack, it’s still always good practice to inform them that someone is still trying to break in and we blocked the attacker from any other activities he/she may do.