Hot answers tagged browser
6
This sounds like an insecure cookie scope. If the application is scoping its cookies to .domain.com then XSS in a sub-domain can lead to an account compromise.
As long the applications are on separate servers, they are not sharing the same database account and cookies are scoped properly there shouldn't be a concern.
4
Basically you are right, your solution would prevent CSRF tokens from being necessary against such attacks. But then we could also check the Referer header to make sure it comes from an allowed domain or subdomain, right? And using the referrer would already be more flexible than an NoCSR-flag: you can whitelist domains or subdomains.
The problem is replay ...
4
Targeting sandboxed platforms like Flash and Java will be excessively difficult if you're just starting out, so I suggest you learn to walk before you try to run.
Some stuff you'll want to know:
How to code in a low level language like C.
What the stack, registers, heap, etc. do, and what happens when you overflow them in various ways.
At least basic x86 ...
4
The purpose is to ensure that XSS vulnerabilities in one webapp doesn't allow compromise of the other webapp.
If you run them on two separate domains (e.g., facebook.com and facebookdevelopers.com; not facebook.com and developers.facebook.com), then the browser same-origin policy provides isolation between the two webapps.
This has been discussed at length ...
3
Check out Fuzzing with DOM Level 2 and 3
"Overview
Fuzzing techniques proved to be very effective in finding vulnerabilities in web browsers.
Over time several valuable fuzzers have been written and some of them (mangleme, cross_fuzz) have became a "de-facto" standard, being widely adopted by the security research community.
The most common ...
3
I'd say mostly complication. A link sent through another application would carry no site referrer, so that is a hole that needs to be considered. One could focus on only passing requests from within the site, but there could be an XSS vulnerability that would create CSRF-like behavior that would be stopped by using a nonce.
In very short summary: the nonce ...
2
Your edit clarifies that you are talking about privacy and anonymity: "eliminate local evidence that you went to the website". That changes the question a bit, as it clarifies you are talking about anonymity, not protection from malware.
The best way to achieve those privacy and anonymity goals is as follows:
For web browsing, use Tor. For chat, use ...
2
The security value of your sandbox depends on the type of sandbox you're talking about. The better you can isolate your writable hardware from the vulnerable software, the better off you are.
Virtualization is theoretically a better option than an API-isolation sandbox because engineering an exploit for the sandbox itself is more difficult to do if it's a ...
2
There are some security benefits to running the browser in a sandbox. If the browser gets compromised, then the sandbox can limit the damage.
However, there are also serious usability implications of running your browser in a sandbox. For instance, say you want to download a document off the web and save it somewhere for later use. Nope, sorry, no can ...
2
Exact duplicate of SO question (which is more relevant than here): http://stackoverflow.com/questions/3868299/is-autocomplete-off-compatible-with-all-modern-browsers
Basically, most modern browsers attempt to respect it, though it would be trivial to write an javascript extension to ignore/disable it. E.g., with jQuery library they could do something like ...
2
That should never happen.
Without any code samples which I can look it, one reason I can envision that happening is an authentication workflow as shown below:
In the following diagram, /login POSTs to /member, where the authentication check takes place.
If authentication passes, the pages continues to send the 'logged in user' content. This makes this ...
2
No
I'm not sure what you mean? You can't "break out" of document.title=AttackerString where AttackerString is a javascript variable with data (the string value) controlled by you.
Again, you can't exploit escape(AttackerString) but you can exploit something like <? echo 'escape("' .$_GET['AttackerString']. '");' ?> by simply bypass the javascript ...
1
Pros
It can improve security when authenticating (in addition to a multi-factor device)
If used as a "client certificate", it can make MITM attacks much more difficult
The Keygen tag is implemented across most non-IE browsers, making it very easy to implement
Works regardless of administrator permission. With IE Active X controls can be disabled and IE ...
1
One of the booleans available to the WebView class is setJavaScriptEnabled. Setting this to true/false will open up the normal vulnerabilities that are available through JavaScript. That said WebView has all the apis available to function as a normal browser. So all the normal precautions should be taken when writing a WebView that accepts user input ...
1
It has nothing to do with the domain IIRC. It's just that it's running on the same webserver under the same user. So to get segregation, you would need to run the webapp under a different user with limited rights. The user your one site is running under should have no rights on files or directories your other user is running under.
Anyway, if you think ...
Only top voted, non community-wiki answers of a minimum length are eligible
