15

When starting an incognito/private browsing session, no cookies from other browsing profiles should exist. For example, if I am logged in to a site on my main browsing profile, then start a new private browsing session, I am not logged into that same site (cookies not carried over). Assuming it is a new private browsing session, there should not be any existing cookies or sensitive information that is available at all.

Does this also have the side effect of preventing or nullifying XSS attacks since there is no sensitive data to steal? Or this is a false sense of security?

|improve this question
  • How precisely would the XSS attack be performed? – curiousguy Oct 21 '18 at 20:47
  • 2
    Using Incognito session, then logging into a bank site that is vulnerable to XSS can cause you to share the sensitive information related to that bank site. – AEonAX Oct 22 '18 at 4:47
  • 13
    Did you maybe mean to ask about CSRF (cross site request forgery - might be confusing as both use cross in their name)? As the other answers explain, XSS is not primarily about abusing cookies. – Nijin22 Oct 22 '18 at 7:37
  • @Nijin22 CSRF attack probably would be more relevant to this question since I was primarily concerned with stealing site cookies, however I was also talking about other sensitive browser data that might also be accessible. Cookies were just my go-to example here. – Jack Oct 22 '18 at 20:10
32

An XSS attack is not primarily about cookies. It is not about stealing sensitive data either. It is instead about executing attacker-controlled code on the client side within the context of the site you visit. What kind of harm can be done by this code depends on the actual site and context.

Using a private browsing session will not prevent XSS by itself but it might limit the impact of what harm XSS can do - i.e. it has no access to the cookies or other stored data from the non-private browser session. It might though still do harm, but again this depends on the specific context and site you visit.

|improve this answer
  • 1
    At best it would prevent an XSS that is somehow related to browser history and more specifict - cookies. For example, if a "bad cookie" can be made for a domain with a value of alert("boo") and that value is blindly executed when you visit that domain, then having no cookies will not trigger that. Depending on the browser it might or might not limit the attack for the current session, though - it seems like Chrome tries to wipe all history after a tab is closed, Firefox will keep something. Maybe sometimes - I'm not entirely clear. Still, stealing cookies is probably the greater threat. – VLAZ Oct 22 '18 at 5:33
3

There are primarily two kinds of XSS-Attacks: Persistent and ad-hoc.

A private Browsing session will protect you from ad-hoc XSS attacks, but not from persistent attacks.

A persistent XSS works by an attacker injecting script-code somewhere into the sensitive page, this could be done by sending you a prepared message on the platform, or by some other means of injecting data into the storage of the sensitive page. When you log into the sensitive page to view some data, the injected data will be loaded by the server and transferred to your browser and will be executed if the site is vulnerable. An example would be a prepared message in an online-banking transaction. The attacker would send you a real transaction and the message-part would contain harmful script. No other page is involved so you cannot protect yourself against this, only the page-owner can.

An ad-hoc XSS can work by getting you to click on a prepared link, which includes injection-data. Such a link could look like https://banking.securebank.com/searchTransaction?query=<script>doEvil(...)</script> where the injected script is part of the link. The attacker will try to get you to click this link, or will try to execute it in the background via JavaScript from his own prepared page. So if you open E-Mail links and untrusted pages in a separate session, your user-account on the sensitive page will be safe from this kind of attack, since you are not logged in on the sensitive page in the incognito session. So while the XSS might still execute, it cannot do any harm to your own account on the sensitive page, which is what we want to protect.

|improve this answer
  • 5
    And of course there is another kind of XSS-Attack: "Use this neat trick for a better view of your finances, just open the console on your online-banking-page and copy&paste the following cool script: <....>" - common sense can protect you from this attack. – Falco Oct 22 '18 at 7:34
  • 2
    Firefox has a feature that prevents typing into the console until you've agreed to it. – wizzwizz4 Oct 22 '18 at 12:35
1

As Steffen already mentioned, a XSS (cross site scripting attack), does not by definition only work with cookies. If someone gets access to a DB and edits certain fields, which contain script tags that can execute on certain webpages, he can execute a XSS attack.

It just means someone runs scripts in your browser on the page that you are visiting to retrieve information from you (perhaps cookies) or deceive you by adjusting the DOM to for example link a payment button to his faulty website.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.