Mozilla サポートの検索

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

詳しく学ぶ

このスレッドはアーカイブに保管されました。 必要であれば新たに質問してください。

Are undeleted cookies a danger to security?

more options

I am reading an article published by InfoSecInstitute. It explains why cookies can be a security and privacy risk (copy of part the article below).

With this in mind, '''I am wondering how wise it is to keep any cookies that do not expire quickly on their own, but particularly those kept to “help” (for convenience) to avoid MF authentication. If hijacked, the hijackers could get access to what they should not have.'''

Do I understand correctly that not deleting cookies on the computer can open it up to hijackers? If so, is cookie hijacking a frequent occurrence? It seems that there are many methods to hijack cookies. There are websites that do not use HTTPS. Does using VPN help?


"It’s not like you can get a virus from a cookie; after all, they are just simple text files and do not contain any sort of executable. Yet, depending on how cookies are used and exposed, they can represent a serious security risk.

For instance, cookies can be hijacked. As most websites utilize cookies as the only identifiers for user sessions, if a cookie is hijacked, an attacker could be able to impersonate a user and gain unauthorized access.

This may happen in several different ways:

Capturing cookies over insecure channels: Any cookie related to authentication should always be transmitted securely, but that is not always the case. One example is cookies without a security flag. When a cookie is set with the Secure flag, it instructs the browser that the cookie can only be accessed over secure SSL/TLS channels. If the secure flag is not set, a cookie can be transmitted in cleartext — for instance, if the user visits any HTTP URLs within the cookie’s scope. This would allow an attacker eavesdropping network traffic to easily capture the cookie and use it to gain illegitimate access.

Session fixation: This is another attack that allows an attacker to hijack a valid user session. This time, it exploits a limitation in the way the web application manages the session ID. For example, if an application allows a session token in the query parameters, an attacker may send a user an URL with a specific session ID included in its arguments. Now, when the user authenticates by using this URL, the attacker can hijack the session.

Cross-site scripting (XSS): Another way to steal cookies is using cross-site scripting to exploit websites that allows users to post unfiltered HTML and JavaScript content. For example, if a user clicks on a malicious link posted by an attacker, it may execute the JavaScript code and cause the victim’s web browser to send the victim’s cookies to a website the attacker controls.

Cross-site request forgery (CSRF): This is a type of attack that exploits a website by making it execute unauthorized commands that are transmitted from a user that the web application trusts. In a CSRF attack, the attacker’s objective is to use an innocent victim to unknowingly submit a maliciously crafted web request to a website that the victim has privileged access to. Since the victim is already logged, any request coming from his browser will be deemed as trustworthy and be executed.

For an CSRF attack to work, an attacker must first identify a reproducible web request that executes a specific action — for example, changing a password on the target page. Once such a request is identified, a link can be created that generates this malicious request and that link can be embedded on a page within the attacker’s control. Even worse, it may not even be necessary for the victim to click the link. For instance, it may be embedded within an html image tag on an email sent to the victim, which will automatically be loaded when the victim opens their email.

Cookie tossing: A cookie tossing attack is based on providing a user with a malicious cookie that has been designed to look like it came from the targeted site’s subdomain. Of course, this becomes especially problematic when a website allows untrusted people to host subdomains under its domain. When the user visits the target site, all cookies are sent, both valid and the ones appearing to be from subdomains. In this attack, the ability to take over a session is quite limited, because the attacker can only write information, not read anything. However, cookie tossing can be used to set arbitrary cookie values that, in some cases, can be used for a CSRF attack or an XSS injection, depending on what the main domain does with the content of the cookie.

Cookies may also represent a severe risk to privacy. "

I am reading an article published by InfoSecInstitute. It explains why cookies can be a security and privacy risk (copy of part the article below). With this in mind, ''''''''I am wondering how wise it is to keep any cookies that do not expire quickly on their own, but particularly those kept to “help” (for convenience) to avoid MF authentication. If hijacked, the hijackers could get access to what they should not have.'''''''' '''Do I understand correctly that not deleting cookies on the computer can open it up to hijackers? If so, is cookie hijacking a frequent occurrence? It seems that there are many methods to hijack cookies. There are websites that do not use HTTPS. Does using VPN help?''' ---------------------------------- "It’s not like you can get a virus from a cookie; after all, they are just simple text files and do not contain any sort of executable. Yet, depending on how cookies are used and exposed, they can represent a serious security risk. For instance, cookies can be hijacked. As most websites utilize cookies as the only identifiers for user sessions, if a cookie is hijacked, an attacker could be able to impersonate a user and gain unauthorized access. This may happen in several different ways: '''Capturing cookies over insecure channels''': Any cookie related to authentication should always be transmitted securely, but that is not always the case. One example is cookies without a security flag. When a cookie is set with the Secure flag, it instructs the browser that the cookie can only be accessed over secure SSL/TLS channels. If the secure flag is not set, a cookie can be transmitted in cleartext — for instance, if the user visits any HTTP URLs within the cookie’s scope. This would allow an attacker eavesdropping network traffic to easily capture the cookie and use it to gain illegitimate access. '''Session fixation''': This is another attack that allows an attacker to hijack a valid user session. This time, it exploits a limitation in the way the web application manages the session ID. For example, if an application allows a session token in the query parameters, an attacker may send a user an URL with a specific session ID included in its arguments. Now, when the user authenticates by using this URL, the attacker can hijack the session. '''Cross-site scripting (XSS'''): Another way to steal cookies is using cross-site scripting to exploit websites that allows users to post unfiltered HTML and JavaScript content. For example, if a user clicks on a malicious link posted by an attacker, it may execute the JavaScript code and cause the victim’s web browser to send the victim’s cookies to a website the attacker controls. '''Cross-site request forgery (CSRF)''': This is a type of attack that exploits a website by making it execute unauthorized commands that are transmitted from a user that the web application trusts. In a CSRF attack, the attacker’s objective is to use an innocent victim to unknowingly submit a maliciously crafted web request to a website that the victim has privileged access to. Since the victim is already logged, any request coming from his browser will be deemed as trustworthy and be executed. For an CSRF attack to work, an attacker must first identify a reproducible web request that executes a specific action — for example, changing a password on the target page. Once such a request is identified, a link can be created that generates this malicious request and that link can be embedded on a page within the attacker’s control. Even worse, it may not even be necessary for the victim to click the link. For instance, it may be embedded within an html image tag on an email sent to the victim, which will automatically be loaded when the victim opens their email. '''Cookie tossing''': A cookie tossing attack is based on providing a user with a malicious cookie that has been designed to look like it came from the targeted site’s subdomain. Of course, this becomes especially problematic when a website allows untrusted people to host subdomains under its domain. When the user visits the target site, all cookies are sent, both valid and the ones appearing to be from subdomains. In this attack, the ability to take over a session is quite limited, because the attacker can only write information, not read anything. However, cookie tossing can be used to set arbitrary cookie values that, in some cases, can be used for a CSRF attack or an XSS injection, depending on what the main domain does with the content of the cookie. Cookies may also represent a severe risk to privacy. "

この投稿は Sue により に変更されました

すべての返信 (4)

more options

.....

この投稿は jonzn4SUSE により に変更されました

more options

A cookie stores information. What that information is could cause a problem.

Type about:preferences#privacy<enter> in the address bar. The button next to History, select Use Custom Settings.

Turn on Remember My Browsing And Download History At the bottom of the page, turn on Clear History When Firefox Closes. At the far right, press the Settings button. Turn on Cache and Form And Search History, and whatever else you want.

more options

Thanks FredMcD for your pointer. I will check settings for history and learn about them.

more options