1

I have been doing some research as I am looking to implement a form on anther website using an iframe. I understand that an attacker can change the source code of an iframe to point to a script, but how will this effect everyone else as surely that is client side and not server.

An article I read suggested that hackers will be able to record key strokes from an IE bug, but surely that means modifications to the server side code?

I have enabled sandbox mode with sandbox="allow-forms allow-scripts". Is this secure enough or should a different approach be taken? .

Xavier59
  • 2,874
  • 3
  • 17
  • 34
bish
  • 11
  • 1
  • 2

2 Answers2

2

An article I read suggested that hackers will be able to record key strokes from an IE bug, but surely that means modifications to the server side code?

The IE bug I believe you are referring to is mentioned here.

an attacker may create a web page at evil.com, which the attacker controls, and include on the evil.com page a visible frame displaying the login page for example.com. The attacker can hide the frame's borders and expand the frame to cover the entire page, so that it looks to the browser user like he or she is actually visiting example.com The attacker registers some javascript in the main evil.com page which listens for all key events on the page. Normally, this listener would be notified of events only from the main evil.com page -- but because of the browser bug, this listener is notified also of events from the framed example.com page

However, the user would:

  1. Have to be using a vulnerable version of Internet Explorer.
  2. Already be trusting evil.com to enter their credentials for example.com. That is, evil.com could just as well be displaying something which looks like example.com's login page rather than an IFrame.

I have enabled sandbox mode with sandbox="allow-forms allow-scripts". Is this secure enough or should a different approach be taken? .

The main risk if the other website is malicious or compromised, then it can do what it wants within the IFrame only. The sandbox attribute is widely supported, however you may wish to not write the IFrame at all for unsupported browsers. You are not specifying allow-top-navigation so they cannot redirect the user away.

The Same Origin Policy will prevent the framed page from manipulating yours. I guess the main risk you're taking is that the site could attempt a browser exploit or a cross-domain attack on another website (e.g. XSS, CSRF) by you sending the user to a site that they have not chosen to trust.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
-1

No, this isn't enough secure.

  • If you havn't set the header X-Frame-Options: SAMEORIGIN, your site can be display in an iframe. The hacker can use clickjacking : he can put an iframe into the iframe and with a subtile mix of CSS and HTML, get the user click on a button which in reality is a link from the iframe of your site to execute an action with CSRF tokenon your website.
  • Using iframe hack, the hacker can resize the iframe to fill the entire page. He can insert fake contents such as a fake login page. The user will think about a simple disconnection and relog, giving his logs to the attacker.
Xavier59
  • 2,874
  • 3
  • 17
  • 34