Tag Info

New answers tagged

39

The question is asked mostly to protect you from phishing attacks. The website may fake an Operating system, and ask you to enter sensitive information like passwords. To quote the spec: User agents should ensure, e.g. by means of an overlay, that the end user is aware something is displayed fullscreen. User agents should provide a means of exiting ...


0

Are input fields that don’t have name="" sent via the browser Not by the standard HTML form submission process. However JavaScript on the client side can read the contents of the fields and send that data themselves. Are input fields that don’t have name attributes susceptible to MITM attacks (w/o SSL) or any other attack? Yes. All content on a ...


2

Yes. Any HTTP request that isn't protected by SSL/TLS/HTTPS is vulnerable to MitM attacks. Without the integrity that is provided by HTTPS, any component of the HTML served over HTTP is vulnerable to attack or modification by a man-in-the-middle. For instance, the form's action could be changed, so instead of the form being POSTed to your intended page, ...


0

I think the pen test team misspoke. MITM is a much more serious threat than a XSS, because the MITM attacker can monitor and replace any of the content of your site. It's invalid to complain about the content of a site attributing a MITM attack, because the content is irrelevant to a MITM. MITM can always inject content into your site. XSS is a ...


0

Man-in-the-middle might not be the only way to manipulate the cookie. If, for example, the cookie is used for example.org and you have subdomains like user1.example.org which you either don't control or which might have XSS problems, then it will be possible to set the cookie for example.org from user1.example.org. You will probably not be able to read it, ...


1

You would normally be correct, however you cannot protect against this MITM vulnerability even if you use a secure cookie over SSL. This cookie could still be MITM'd to inject XSS. The pen test report is correct - the fact that the XSS mechanism is a cookie gives rise to the MITM vulnerability. This is because the Same Origin Policy for cookies does not ...


3

Your assumption is incorrect, Firefox addons are not inherently more secure than Chrome extensions (though in terms of security, I attach more value to Firefox's official addon gallery (AMO) than the Chrome Web Store because all addons on AMO are manually reviewed). Addons in Firefox are trusted by design; they can do anything that is allowed by the Firefox ...


2

In the ClientHello message, the client announces its maximum supported version. Previous versions are assumed to be supported as well (in the SSL 3.0 to TLS 1.2 lineage at least; SSL 2.0 used a very different format). Cipher suites are "backward compatible": for instance, SSL_RSA_WITH_RC4_128_SHA has value 0x0005 in SSL 3.0, and the corresponding cipher ...


0

The address bar doesn't do anything. It's the web application which appearently takes the URL and inserts it right into the HTML markup, leading to a cross-site scripting vulnerability. This happens either server-side or client-side: Either the PHP script delivers the page with the URL already in it, or there's a piece of JavaScript code which injects the ...


0

That is the same as filling a form which has an input field named page with the following data text-file-viewer.php/"><script>alert("test");</script> If you get the alert pop-up, the server is writing the user input as is.


13

JavaScript, the Definitive Guide, 4th Edition - published in 2001 - mentions these in a bit more detail. The relevant section appears to be freely available. It's right at the bottom of that link. Here's the excerpt: 12.2.5. JavaScript in Nonstandard Contexts Both Netscape and Microsoft have implemented proprietary extensions in their browsers, and ...


0

DOM XSS are as dangerous as reflected XSS. To exploit it the attacker always needs to induce a client to create a request (f.e. by clicking some link that still points to the considered safe site). After this has been done, you can execure JavaScript on the client's browser. This can lead to all sort of attacks on the browser!


3

Browser usually cache intermediate certificates which they've seen once. This can be tested if you use firefox against a server which missing a common intermediate certificate. If the browser has seen this missing certificate already it will allow the connection. But, if you use a fresh firefox profile and retry it will complain, because the certificate ...


12

In SSL/TLS the server is supposed to show its certificate as part of a chain. Theoretically, the server should make sure that the sent chain is correct, and the client is "morally entitled" to reject the connection if the exact chain sent by the server fails to validate. However, clients are allowed to make extra efforts; if they can validate the certificate ...


2

User-agent strings do provide the companies running web servers with useful information. If they're contemplating introducing web site features or content they want to know if the majority of their user base have browsers that support that technology. They can look at the user-agent strings logged in the past month or two and get a sense of what browsers ...


0

Probably has more to do with dofeqilr.com than with your specific subdomain thereof. http://www.spamhaus.org/query/dbl?domain=dofeqilr.com


8

In order to do any damage to your computer or data stored on it, the page would have to either exploit a security vulnerability in software on your computer or prompt you with an additional confirmation dialogue. The warning may be due to the page exploiting a security vulnerability for which there is not yet a patch available, so the warning should be ...


16

Yes there are known attacks of this type. The site you are trying to visit is one. That's why your browser is telling you not to visit the page. Javascript files included on pages are always executed by the browser. That's what Javascript does. Whether or not it has the necessary privileges to do something malicious is where the battle is at. It is unlikely ...


1

Well if you are using Firefox you can use NoScript but right now "Canvas Fingerprinting" is really a new buzz word but when more people know about it the more developers will make addons to counter Canvas Fingerprinting. There are several options to block Canvas fingerprinting TOR web browser. Yesscript. More info here Canvas Fingerprinting



Top 50 recent answers are included