Since HackerOne came into the system to create close connection between white hats and tech. companies (primarily for security reasons), we have come across terminologies like CSRF, XSS, SQLi and the Poisoned null byte. These terminologies are part of today’s most common, harmful vulnerabilities affecting web applications. Major tech. companies (Google, PayPal, Uber, and Twitter) have benefited from white hats or security researchers like @Rafaybaloch, filedescriptor , and Egor Hakimov’s willingness to help detect hidden bugs or technical mistakes yet unknown to developers and programmers.
However, it seems outsiders still find it difficult to differentiate between XSS and CSRF. We should not interchange XSS with CSRF. XSS and CSRF don’t apply to each other.
Definition of XSS
XSS simply means cross site scripting. XSS is a code attack method used by hackers to inject malicious script.
In XSS attack, attackers exploit the trust the user has for a particular webiste. Generally like all injection attacks, XSS takes advantage of the fact that browser’s can’t tell a valid markup. The attackers do not directly target their victims. They look for vulnerability in a website to inject and deliver malicious scripts for users.
An attacker can access users cookies associated with the website via document.cookie, post them to his own server and use them to extract and access sensitive information like session ID’s. Attackers can also steal credit card details, bypass restriction in websites and perform denial of service attacks.
Definition Of CSRF
CSRF simply means Cross Site Request Forgery. In a CSRF attack, an attacker exploits a website’s assumption that all requests originate from a user’s browser. Logically, a website assumes that all requests that originate from the browser are those of the user.
The attack is possible when the targeted application does not verify and validate the origin of the request. A website relies only on the existence of a valid session between the user’s browser and the application server.
Attackers depend on active sessions to implement CSRF attack successfully. An attacker can use a user’s browser session to send valid report (via GET method or even a POST method occasionally) to a web server to perform certain actions in a user’s account in favour of the attacker.
Facebook, Twitter, and slack have created ‘my account page’, or ‘payment settings’ for users on their platform to store as well as change their details – Password, Age, Email address, and Credit card credentials.
If users can change information on a webpage via both GET and POST method, then it is extremely possible for an attacker to forge request of a user’s mail address. In a CSRF attack, attackers take advantage of or abuse a website’s zero intelligence to forge a request. CSRF attack entails forgery.