I know my website is being breached by a third-party web application under the following scenario:

  1. My users put credentials to my site into a third-party web application

  2. The third-party web application violates my X-Frame Options Deny policy via a Google Chrome Extension. It Iframes my website.

  3. The third-party web application then logs into my website with the credentials the user gave it.

  4. The third-party web application submits information to my website.

Under this scenario, in my log files is there anyway for me to see what pages the third party application is visiting in my secure site and is there anyway to determine if this application is extracting information from my secure webpages?

Also any tips on how to block this third-party web application from being able to iframe my site is much appreciated.

Thanks for your input!

  • why not just check to see if you're in an iframe and do something benign if so? if(window!=top) return alert("fuck off"). you should be able to compare top (no properties) without SOP violation. – dandavis Mar 4 '18 at 6:48

You can attack the extension

I believe it is possible to kill other javascript scripts as shown by:

  • Fuck Adblock
  • Fuck Fuck Adblock
  • Fuck Fuck Fuck Adblock

etc etc

I'm not clear on how this works, but if you know what the script is called/and or get your hands on a copy of it, you can easily begin a sort of 'arms race' against this chrome extension.

You can try to identify the browser application

Then blacklist the hell outta them, but this might just ignite an arms race, where they find countermeasures for your countermeasures etc..

You can screw with their application

If you can get your hands on their scripts and stuff, you can definitely screw with them in the following ways:

  • Identify how they get the password, and feed it fake information
  • Probability of failure for their methods
  • Honeycombed area after login to collect information on updates their scripts may have gotten

You can add two factor authentication/ ip login stuffs

2FA is a brick wall to hackers.

You can ruin automation

In order to get passwords, they're probably scraping the field's identifier. Bots I make use getelementbyid so if you can generate the username and password field ID on the fly, that could be frustrating for the hackers. Might be really frustrating for people that use password autofill though.

Final notes

In any case, your priorities are

  • get your hands on their code
  • figure out a way to identify their login attempts
  • their IP, subpoena their ISP etc etc etc

With these things, you can do any array of things, including playing 'Mr. Passive Aggressive,' where you can move the hacker's session to a different gui compared to everyone else where it can't get any information/get wrong information 50%/50% of the time. Or utilize any methods listed above. In any case, make it difficult for them to identify the methods you use. If you're too hard a target, they'll move on and find someone else.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.