DEV Community

CORS, XSS and CSRF with examples in 10 minutes

Aleksandar Maletic on December 23, 2019

This article should be your entry point for existing web security standards, most common web attacks and the methods to prevent them. At the end, y...
Collapse
 
sandordargo profile image
Sandor Dargo

Thanks for the nice explanation.

I just want to add a remark.

"Vulnerability for XSS is coming from unprotected and not sanitized user inputs those are directly stored in database and displayed to other users."

This is only about the third of the truth. What you wrote about is stored XSS, but there are other types of XSS vulnerabilities, such as reflected XSS and DOM based XSS.

Storing the user's input in a database on the server-side is not mandatory, in fact, it's not even necessary to send any data from the client to the server to be able to speak about XSS.

In case of reflected XSS, the malicious script is encoded in the URL, the attacker broadcasts it, the unaware folks click on it and boom. Here is an example from Shopify.

A DOM based XSS attack will not even necessary send any data to the server. Again, the script can be encoded in the URL, after a fragment identifier (#).

The attacker sends the link who clicks on it, the browser changes the DOM after the page was already loaded and then the JS code executes. As the malicious part never touches the server, this type of attack requires different protection which is based on the client-side completely.

Here is a more thorough explanation.

Collapse
 
maleta profile image
Aleksandar Maletic

Hello Sandor,

Thanks for pointing out on skipped XSS vulnerabilities! I will update article in next few days.

Collapse
 
tomlefley profile image
Tom Lefley

A great write-up and the diagrams are spot on!

In addition to the OWASP resources, I can also recommend PortSwigger's Web Security Academy for worked examples and interactive labs regarding these topics. (Full disclosure of bias; I worked on it)

Collapse
 
maleta profile image
Aleksandar Maletic

Thanks!

Collapse
 
gergelypolonkai profile image
Gergely Polonkai

CSRF can also be prevented by using same-site cookies. Here is a nice article on the subject (although, despite the postʼs title, CSRF is definitely not dead, as it works only in modern(ish) browsers).

Collapse
 
jignex profile image
Jignesh Thummar

very simple to understand thanks..

Collapse
 
maleta profile image
Aleksandar Maletic

I am glad it was simple. You welcome.

Collapse
 
joel23viky profile image
joel23viky

Es excelente me gusta

Collapse
 
xx profile image
qwerty

Nice post, definitely saving it!

Collapse
 
harrywynnwill profile image
Harry Wynn-Williams

Awesome blog! V clear explanation.

Collapse
 
maleta profile image
Aleksandar Maletic

Thank you!

Collapse
 
pureabsolute profile image
Gerard ONeill

Nice. But the CSRF scenario you presented is dealt with via the Same Origin protections, and CORS. If the request is a "simple" get (I think the headers also have to be simple), it is sent to the good site with an origin header that the site can accept or reject. A response is received by the browser, but will be blanked out if the correct CORS header response isn't returned. For other requests, a CORS request is sent including the origin and headers expected, which the good site has to manage. If it doesn't, the request fails. If it does, and rejects the request, then the request fails. If it deals with the request but doesn't send back the correct CORS headers, the browser will blank out the response.

So CORS works with the Same Origin policy to allow exceptions that the site can can use to determine if the request should be honored - which might occur with third party add ins such as a comment system, or a banking app.

Perhaps the CSRF Token was a past workaround; I haven't heard of it.. Or it might be a current workaround for sites that don't have access to the server's headers. If it's in use for a good reason, it would be great to know and I'm all ears!