New answers tagged

1

You can not reliably detect devices, and nor do you need to. Just use the timestamp to routinely delete sessions that are more than X hours old. Note it's perfectly fine to have redundant data in a working table such as this, which was your original concern. You will need to do that anyway since sessions should always be terminated server side as well as ...


1

The main risk of a persistent session is increased exposure for any existing client-side vulnerabilities (e.g. XSS, CSRF, session fixation, etc). That is, any malicious site targeting your users through exploits for the above would be more likely to succeed because the user is left logged in. With remember-me the above could apply too - Say the long-term ...


0

(I already had some thoughts on the matter but was seeking further opinions. Since I seem to have caused some confusion, setting them out here may help in understanding the problem I am trying to address). There are very definite functional impacts, particularly if the developer chooses to use the session substrate for storing transactional information, but ...


3

The problem Imagine the following scenario: Alice logs in to your site on her computer at home, and stays logged in. Later she logs in on a computer at school as well, but signs out when she is done. What happends when she gets home? To make this system work, you would need to set the cookie column to NULL on logout. But that would log her out from all ...


1

Cause it's easier to use a session hijacking attack... More about it here https://www.owasp.org/index.php/Session_hijacking_attack


1

There are multiple reasons for this (sending data all over the place). If you are phishing with the intent of exploiting something, you may have something like mod_redirect running in the background to target specifics. E.g.: if UserAgent = IE && Windows 7 then send them to this particular page with Win7 IE specific exploits or if UserAgent = ...


5

It's essentially spam, in the form of referral headers, so it shows up in your analytics system. If they are causing a problem due to traffic volume, feel free to block them (by whatever means you like - anything with the same name structure is junk), otherwise, they don't do anything. Don't install anything from the pages they link to though, as it can be ...


3

HPKP could be used for tracking in big scale since it has report URIs: Send HPKP header with includeSubdomains set and a report-uri with unique random generated parameter. Embed a hidden image from a subdomain that uses a invalid/not pinned certificate. Browser calls report-uri with unique parameter. Only issue I see is a new report-uri with new UID ...


3

Anything that went over HTTP through a proxy was available to proxy controller. HTTPS you should be okay, depending on the CAs that your browser trusts and assuming that you didn't click "yes" on trusting an untrusted certificate.


3

The short answer, albeit deceiving without the long answer: Yes, a cookie can carry a virus. Yes, it is possible to get such a virus by merely visiting a website delivering the cookie. In the above paragraph, replace "a cookie" with "any file, data, or anything else," and replace "visiting a website" with "possessing," and the statement still holds true. ...


-2

The question of whether or not cookies can be dangerous or spread viruses has to do with whether or not a file is an "executable" one. In theory, if an executable cookie was set with malicious contents, then it is possible that it could affect your computer with a virus and open a proverbial can of worms. This is a fairly rare occurrence and one that I have ...


4

Theoretically they can, as Anders already mentioned. The "problem" is that they won't be executed by the browser. However, another software/malware on your computer could. Which would be particularly dangerous, because anti virus programs most likely won't detect the cookie or the executing software on their own when carried out in separate files.


10

In addition to Anders' excellent answer, there was a vulnerability in Internet Explorer 5 and 6 which allowed a malicious cookie to be set that could then read or set other sites cookie values. Article here. An information disclosure vulnerability related to the handling of script within cookies that could allow one site to read the cookies of ...


3

The cookie itself does not do damage, but it may contain code used by executables. A tactic of some viruses is to store the cookie with some partial code and that code will be alter run by a virus-like application. Example: cookie stores decryption key for an executable that bypasses initial scans due to being well encrypted. Then the .exe is using the key ...


89

You can put any text strings into a cookie, so in theory you could put some kind of code there. But for code to do any harm something needs to run it. The web browser does not interpret the content of cookies as code and does not try to run it, so cookies should not be dangerous. (If you have heard cookies being referenced in security related discussions, it ...


6

Cookies can only transfer TEXT values, meaning it cannot harm your computer stand-alone, but it can contain very important informations, that can be used against you if stolen. Read about Session hijacking, and you will understand what specificaly the exploiter can use it for.



Top 50 recent answers are included