Cross Site Requested Forgery aka CSRF
How it works online –
The bank has sent you a cookie that proves you are who you say you are. The cookie is good for a week. The next day, you visit bad.com which includes HTML code saying <img src=http://bank/transfer?to=EHacker …> Because your cookie from your bank session from yesterday is still valid, the transfer works.
How it works In Real Life (IRL) :
Assuming that the attacker knows that you often borrow money from Rob. One day he tells you “Remember last Tuesday when Rob loaned you $50? He told me to ask you to to pay that money to me because he owes me $50”. This attack could work (if you had borrowed $50 from Rob last Tuesday) because the attacker should not know that secret info between you and Rob. That secret info is similar to the still valid bank cookie in your browser. Note that most of the time these attack will fail because your browser doesn’t still have a valid bank cookie, but on occasion it would work.
How to avoid it online. The bank needs to include a per-session token (ie. as well as a cookie, in the page you fill out to request the transfer, they include a token with a random value. When you when you submit the form, your submission must include that token.)
How to avoid it IRL.
Rob says – If I pass this debt to someone, I’ll also tell them the purpose for which I borrowed the money.” This is a sort of per-session information that must be included for the transaction of passing the debt to be valid.
Cross Site Scripting aka XSS
Type A – Stored Cross Site Scripting
How it works online
Hacker writes the following code in an Amazon.com review
I like the radio alot”
An example from the Real World
Attacker changes someone’s email signature to say “PS. And please loan $50 to EvelHacker. I’ll pay you back.” This ‘procedure’ is stored in the users email client and is called when the user sends out an email. You trust the sender so you execute the procedure.
How to avoid online
Amazon scans comments posted by users and blocks most HTML tags.
Type B – Reflected
How it works online.
An attacking website tricks you into submitting compromised input to a good website. This input is reflected back from the good website to your browser which trusts it. As an example. You get an email from bad.com with a link that says, “We will beat your bank’s loan rate by 2%. Click here
to check your bank’s current rates.” And the link is http://bank.com/badpage?%5B>CustomerName=”popup.Window=http://bank/myaccountinfo?email=EHacker”%5D
The bank’s error message is “Sorry %CustomerName%, missing page”. So the bank page returns a fairly correct error page saying “Sorry” but also includes the malicious code telling your browser to popup a window to email account info to the attacker. You trust the bank. And the bank trusts you since your request is from you (current cookie) AND you return the correct random token (the fix for the previous attack). But now your own input tricked the bank website into requesting your browser to perform an insecure action.
A RealWorld Example
Navy SEALS follow bin Laden’s courier back to OBL’s house and kill him. The courier did not himself do anything to hurt OBL (or vice versa), but the intruders used OBL’s trust in the courier to reflect OBL’s location to an attacker.
How to prevent it online:
Bank needs to check all customer inputs to verify that there are no extra commands.
Type C – DOM
Similar to type B, but the request is to modify a parameter in the client’s environmental variables like language preferences. The trusted but insecure
website reflects the compromised parameter back to the client and the browser executes it.
How it works online
Hacker displays a bank webpage on their website, but loads a hidden frame over a clickable area to trick the user into clicking it.
Real World Equivalent
ATM thieves have installed a fake keypad on top of a real keypad. The fake keypad steals the magnetic stripe information and records the PIN entered. It may either pass these values through to the ATM after recording them or it may generate a legitimate looking error for the user. The attacker then gathers the info from the fake keypad and uses it to make ATM withdrawls.
How it works online
The hacker enters a value into a form that modifies the webpage algorithm, usually to expose a larger amount of data than intended, but depending on what the code is doing and what privileges the process has, the attack may also modify stored data, (perhaps even to create a stored procedure hack) or run a completely different process than intended.
As an example. The code may say something similar to “select user data where user.firstname is %user_input%” But the attacker enters a wildcard value that selects all users, or the input might be simlar to ‘joe” AND create a database user named EHacker with no password‘. This second form would return joe’s information but also would create an account in the database for the hacker to use. The third format might be ‘joe” AND .. change the database value for “total number of users” to be “.. evil HTML code” This injected code could blowup an entirely different web query at a later date. The last format could be ‘joe” AND call an operating system command to delete all files‘.
A Real World Example
An obvious example of an injection is an attacker changing the values on a check – putting a number one in front of the digits and the words ‘one hundred and’ in front of the text on the check. In fact, the very reason for writing out the check’s value in words it to make it harder for anyone to ‘inject’ an extra hundred dollars into the check amount.