This would complete the
whois
command being run with the domain name
wub‐
ble.com
. The delimiter then says, “wait a second, I have another command to run
after the first one is finished.” So, the operating system will also run the next com‐
mand. All of the output from both would be fed back to the page being presented to
the user. This would show the
whois
output but also the contents of the
/etc/passwd
file.
This attack targets the server that processes whatever system command is meant to be
run. Any command that can be executed by the user that owns the process can be
passed in. This means an attacker can gain control of the system. This is probably the
web server, but it could be the application server as well.
Cross-Site Scripting
So far, the attacks have been focused on the server side. Not all attacks, though, are
focused on the servers or the web infrastructure that houses the application. In some
cases, the target is the user or something that the user has. This is the case with cross-
site scripting.
Cross-site scripting
is another injection attack, but in this case, the injec‐
tion is a scripting language that will be run within the context of the user’s browser.
Commonly, the language used is JavaScript since it’s reasonably universal. Other
scripting languages that can be run inside a browser, like Visual Basic Script
(VBScript), may also be used, though they may be platform dependent.
There are two types of cross-site scripting attack. One is
persistent
. A persistent cross-
site scripting attack stores the script on the web server. Don’t be confused by this,
however. Just because the script is stored on the web server doesn’t mean that the web
server is the target. The script is no more run on the server than HTML is. In each
case, the browser processes the language. With HTML, the language tells the browser
how to render the page. With something like JavaScript, the script can get the
browser to do anything that the language and the browser context allows. Some
browsers implement something like a sandbox in order to contain any activity.
With persistent cross-site scripting, the attacker finds a website that allows for the
storage and subsequent retrieval and display of data provided by the user. When that
happens, the attacker can load a script into the server that will be displayed to users
who later visit the page. This is a good way to easily attack several systems. Anyone
visiting the page will run the script, performing whatever function the attacker wants.
A simple way to test for a cross-site scripting vulnerability is to load something like
into a field that leads to persistent storage. An early
avenue of attack was discussion forums. The attacker could load up a forum with an
attack and wait for people to come visit.
The thing about this, though, is that you may think an easy mitigation is to just block
the characters < and >. That keeps the tags from being stored and interpreted later as
