Month: February 2019

Both Cross-site Scripting/XSS and Cross-site Request Forgery/CSRF are browser exploits. XSS does not necessarily use an authenticated session; the vulnerability attempts to inject untrusted code in the web page / web app. In an authenticated session, the CSRF vulnerability injects/modifies a link or form that is able to take advantage of the current session.

Cross-site Scripting (XSS)
XSS is a vulnerability listed as A7 in the OWASP Top Ten Project. It is an attack directed at the user of the web browser (or web app).

In XSS, a web page is sent from the server to the browser with a script (or a link) that is hidden by a malicious attacker.

XSS Attacks

• Other web sites (via, for example, query/request parameters). This was the original vulnerability, and why the vulnerability is called “Cross Site”. A more appropriate name now might be “Script Injection”, but I digress.
• Server Vulnerability that allowed the script to be replaced/stored on the server.
• Network. Prior to the common use of TLS, Internet Service Providers have been known to inject javascript into web pages passing through their network to facilitate such things as analytics, advertising, etc.
• Local. Malware that has access to the browser can potentially alter the environment.

Cross-site Request Forgery (CSRF)
XSS is vulnerability no longer makes the OWASP Top Ten Project as this vulnerability is nearly eradicated due to the use of hardened frameworks. Only about 5% of applications have been found to be vulnerable (2017).

A common occurrence of CSRF is if a target was in a session authenticated to a target server, and that target server does not have proper controls in place. The bad-guy could blindly present a link on his web site that just happened to reference the target server that, if clicked, would causes an action on the target server in the context of an authenticated session.

Keywords: csrf, csf, rsr, javascript, java script, perl, flash, browser, dom, xss, css, cs