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...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the nice explanation.
I just want to add a remark.
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.
Hello Sandor,
Thanks for pointing out on skipped XSS vulnerabilities! I will update article in next few days.
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)
Thanks!
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).
very simple to understand thanks..
I am glad it was simple. You welcome.
Es excelente me gusta
Nice post, definitely saving it!
Awesome blog! V clear explanation.
Thank you!
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!