-
Notifications
You must be signed in to change notification settings - Fork 0
Website Attacks
Hackers inject their code into our web page, when their code runs do some malicious things to our web site or to our user, for example stealing our web site data. The goal to protect our web site from this attack is to prevent such code from executing.
How can hacker’s code get injected into our document? Some of our web page contains user entries, such as having a form allowing users to fill the form then display the data they entered in the form. Hackers may possibly enter their malicious code in those form fields.
What can hacker’s code do? If their code get executed, these code can do whatever our own code can do. For example, read cookie value, send request to our server and access response. Once their code steals our data, they can send these data to their server.
Make cookie httponly is a way to prevent hacker’s code from accessing and stealing cookie data.
- Rob Shapland, Cross-site request forgery: Lessons from a CSRF attack example
- Cross site request forgery (CSRF) attack
- Common CSRF Prevention Misconceptions
Attackers allure our user to submit request to our website unintentionally to cause some damage to the user or to the website. The submit form or submit code comes form attacker, although that form submits request to our website.
The prerequisite for this attack to work is the user has logged in to our website, and their identity is stored in cookie.
It utilizes the following nature of the cookie: cookie sends with request to site that belongs to the domain this cookie belongs to, regardless the origin of the document that submits the request.
Such a request can be made by a user clicking a hyperlink in an email he receives, or by a script that runs when a user load a document.
While we need to know what CSRF attack can do, we also need to understand what it cannot do
- CSRF attacker cannot read or change cookies in our site
- CSRF attacker cannot access the response of our site，thus has no access to our data. Therefore only state-changing requests need CSRF protection https://security.stackexchange.com/questions/115794/should-i-use-csrf-protection-for-get-requests
CSRF Attack Solutions
- Harsha Kavinda, Synchronizer Token Pattern: when user logs in, generate a token and set it as a session variable. Then in every form sends to user, add that session variable value in a hidden field in the form. Once receives the form data submitted by user, check if that hidden field value matches the session variable value
- Harsha Kavinda, Double Submit Cookie Pattern: when user logs in, generate a token and put it in cookie. Then in every form sends to user, add that cookie value in a hidden field in the form. Once receives the form data submitted by user, check if that hidden field value matches the cookie value