Tag Info

New answers tagged

3

Anonymous navigation is a confusing term. The navigation is not anonymous, it only leaves less traces on the computer. Even if you disable that funcionality, the user could instruct the browser to wipe all data, and get the same. Or s/he could make the AppData folder for Chrome read-only, and get the same effect. There's better ways to do that. The easier ...


3

You can do this with a GPO. Go to Computer Configuration > Administrative Templates > Google > Google Chrome. Look for a folder named Allowed extensions. There configure a blacklist of *. This will prevent users from installing plugins.


0

There is the sand cat projet which provide a lot of pen testing tools, like scripting in lua, better view over the console and dynamic injection tools, and a lot of other good surprise.


3

When something like Burp finds an XSS vulnerability, I can't ever verify it when using something like TamperData. If you are already using Burp to find the vulnerability, why not use the intercepting proxy functionality to modify the request and to inject the XSS payload?


5

Your best bet would be mantra from OWASP: http://www.getmantra.com/ Contains a myriad of tools for penetration testing out of the box. Also open source should you need to add/modify anything.


8

Most browsers allow you to disable the function. For instance with chrome you need to start the browser using C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --args --disable-web-security For Firefox you have to go type about:config in the address bar. Then you need to set the browser.urlbar.filter.javascript to False. For Internet Explorer ...


5

I did visit the page (from a safe place!) and it's triggering the beforeunload event to change the URL, like this: var exit=true; var temp_url = document.location.href; var url_pieces = new Array(); url_pieces = temp_url.split("/"); var goto_url = 'http://www.imagesnake.com/ad.html' ; window.onbeforeunload = function () { if(exit==true){ ...


70

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 ...



Top 50 recent answers are included