0

I am learning to design a system where it can be guarded against XSS & CSRF attack.
I'll quickly list down my understanding and then raise questions.
It's a simple case of fraud that I am trying to avoid.

Steps mentioned below are executed by hacker:

  1. Broadcast e-mail to a lot of people holding account with any specific bank on gmail yahoo etc.
  2. Once mail is received, script in background is executed from the email on-load , it checks if bank website is open in any of the tabs. If not, try after regular interval.
  3. Hacker is aware that in the post request, only his account number needs to be updated and money would be transferred to his account
  4. Common logic is written in front-end code which adds the headers and cookies on ever request sent to server.

Question:
Is the above attack possible?

Answers: (From my understanding)
If hacker knows the payload required for fund transfer, hacker would simply hook onto mouse movement event and being aware about the url and payload would fire the request for fund transfer.
Cookies and other header details would be passed along as front-end team for simplicity have written logic to add these fields with every http request.
Please corrent me if I am wrong.

Please highlight if any of the steps undertaken by hacker(1-4) are not practically possible

AleksanderCH
  • 711
  • 3
  • 10
  • 23
  • In order to avoid opinion based answers, multiple questions about the same topic could be done in separate questions. That being said. XSS can be prevented, check the [OWASP cheatsheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.md) – bradbury9 Mar 25 '19 at 14:13
  • updated to single question – Always a newComer Mar 25 '19 at 14:18
  • 1
    (2) isn’t possible thanks to the same-origin policy. If a script on your website could make credentialed requests to every other website, that would be a serious issue, yeah. – Ry- Mar 25 '19 at 21:58
  • The script would be making request to the same site but with account number of the hacker. Cross-origin policy would not stop in that case – Always a newComer Mar 26 '19 at 04:59
  • 2-4 are impossible; 2 literally. 3 that's not how anything with money is setup for 20 years. 4. clients can only set headers to their own site servers. – dandavis Mar 26 '19 at 17:14

1 Answers1

1

Ok so technically anything is possible, but there would need to be a lot of very unordinary things in place for this scenario to play out as described. Lets start out with point #1...

1) An email is broadcasted to lots of members of a certain bank website. This is very possible, and is known as a phishing attack. These attacks are common, but in order for them to be as deadly as the scenario you described, there would need to be major flaws in the banking website.

2) A script is executed in the background of the email that checks for open connections to the banking website. This is fairly inaccurate. Starting off, mail XSS vulnerabilities are very rare nowadays (and pretty much always have been). Here is a discussion about XSS in emails, and here is a good read on XSS if you didn't already know what it was. In the rare case that an email service would have a XSS vulnerability in the body of an email, malicious javascript could be executed, but it could not read open tabs and information associated with them (it could open new tabs, but not read if a connection exists).

3) Hacker sends his account number in a POST request. This sort of thing usually takes place when there is a CSRF vulnerability. A CSRF vulnerability allows an external site to make possibly destructive requests to the site. Here is a good read on CSRF. Basically, if the banking website didn't use any CSRF token to verify money being sent, the hacker could phish a member of the bank to click on a link that makes a "send-money" request to the hacker's account. This attack is basically 100% nonexistent in banks today.

4) Common logic and headers / cookies are always manipulated with front end code. This would be incorrect because although cookies can be edited on the front end, they are also commonly created and read on a server. Here is a good read on cookies and here is a good read on headers.

Considering the last part you wrote about the answers, to my knowledge, a hacker can't latch onto a user's mouse movement without actually breaching the computer, which is very difficult and uncommon. Hope you found this useful!

Michael Hoefler
  • 145
  • 2
  • 9