Tag Info

New answers tagged

1

You must always clear your cookies. Except in one case. A cookie is just a text file where some information in plaintext format is stored. But you can not get an answer if you do not know the type of cookies that exist: Transient Cookies (called also session cookies, non-persistent cookies or in-memory cookies): they are stored in the RAM and they are ...


2

Cookies by themselves do not create any vulnerability. The goal to delete cookies is merely to improve privacy by keeping websites from tracking your activity. A common way to track users, for instance, is when you visit several websites which include contents from some defined third-party tracking service (this content may be advertisement for the ...


0

As the commentators suggested you correctly, you will need to use the HttpOnly fla as a solution. But I just want to add a note regarding the right comments you received about HttpOnly flag. In fact, if a client of your website uses a Mozilla Firefox browser of version before 3.0.6 (Bug 380418: XMLHttpRequest allows reading HTTPOnly cookies) and/or ...


1

Yes it is possible. If tokens are server generated by creating a cryptographically secure random sequence stored against the account, this token could be refreshed and reissued on a certain interval, invalidating the old one. The token would only be refreshed on active use so it won't invalidate the old one when the client computer is off. This approach ...


0

Is it possible to implement a login system that protects against this scenario, while still allowing your user the convenience of "Remember this computer for 30 days"? No. To put it bluntly, it is impossible. That will be a huge, complicated and simply a non feasible task for an authentication system to fulfill. All what you can do is to be ...


1

A lot depends on what it is your trying to do and what the risks are associated with session hijacking. Generally, if you have a real need to ensure the session is actually owned by the right user, you would add additional checks, such as username and password etc. The EFF has been doing a bit of work on how you can do browser fingerprinting to track ...


5

Session state within an application should ideally be managed server-side from a security perspective. So in terms of expiry a list of active sessions should be stored and they should be removed from the server after an agreed period of inactivity (exactly what this would be depends on the application sensitivity, user base etc) The application should also ...


2

This sounds fine, and seems like a good solution to protect the session cookie against XSS attacks by duplicating the value of username into a non-http only cookie. All your authorisation checks should be being made server-side anyway. So if your client wants to do something server-side, it sends the request and then the server makes the authorisation ...


2

Well, the server HAS to set this flag on the cookie, if it doesn't, client side scripts such as javascript snippets in a XSS style attack can access the cookie contents. Also, you might want to look at XST(Cross-Site Tracing) which i believe can bypass this flag and allow stealing cookies in some scenarios. From the wiki page for it: Tagging a cookie ...


1

Is there any prior research that describes how a cookie, or cookie alternative would be used to provide such a guarantee? I don't think you can provide such a guarantee, except by perhaps saying so in your privacy policy and then following that policy. The scope would be restricted to a one, or a very limited set of URLs, Setting scope can be ...


3

If implemented correctly, HttpOnly prevents an attacker stealing the cookie. However HttpOnly feature can be bypassed in certain versions of some browsers and web servers. Take a look: https://lwn.net/Articles/646891/ https://www.youtube.com/watch?v=jrKOdWPZtAg https://bugzilla.redhat.com/show_bug.cgi?id=1222923 So in summary HttpOnly makes things ...


0

When HTTP Only flag is set tot true on the server side then there is no other way to steal the cookie using XSS.In modern web browsers like Chrome there is no way to see the cookies using xss because the xss filters are enabled by default. If it is not enabled on the browser then there is also a way to enable the XSS filter in the browser from a server ...


4

But that means that XSS is not for cookie stealing anymore? In short, no, XSS isn't used to steal cookies when this flag is set. The longer answer is that modern browsers support the HttpOnly flag on cookies. This flag can be set when the server sends a Set-Cookie header to the browser to keep document.cookie from getting the contents of cookies. It is ...


3

I was planning on user AES256 to ensure the client can't change the value of the cookie. Encryption provides confidentiality, it does not provide authentication. If you do not want users to see a session data value, then you should encrypt then authenticate the value. This prevents a bit flipping attack from changing the value inside of the encrypted ...


2

Encryption alone is not enough because it only provides confidentiality and this task also requires authenticity. If the plaintext in the attacker's cookie contains something like User number 9 is authenticated then the attacker can change bits in the ciphertext that when it is decrypted on the server it will say User number 1 is authenticated and be ...


5

From OWASP: In order to minimize the time period an attacker can launch attacks over active sessions and hijack them, it is mandatory to set expiration timeouts for every session, establishing the amount of time a session will remain active. Insufficient session expiration by the web application increases the exposure of other session-based ...


1

I don't think this will provide any benefit. On a secure web application, the less you depend on client data, the better. I can see some issues: This will surely create a vulnerability named Session Fixation: an attacker can create a session, lure your client to a special page, and have the session data on his hands. The server has no means to know if a ...


0

I think you should send %E5%98%8D%E5%98%8A, not %E5%98%8A%E5%98%8D. Otherwise both tokens get expanded and you probably end up with an extra newline. On the other hand, the extra newline apparently is not interpreted at all, so I'm wondering if your exploit is indeed working, or whether you're seeing your own payload echoed back harmlessly to you and then ...


0

I had to read your question a couple of times to understand what you were describing in option one - if your session cookie contains a predictable, clear text value (in your example the authenticated username and the redundant fact that they are authenticated) then your security is fundamentally broken. Session is should be random or encrypted with time ...


0

I would try to just do something like this: http://www.example.com/somepage.php?page=%0d%0aContent-Type: text/html%0d%0aHTTP/1.1 200 OK%0d%0aContent-Type: text/html%0d%0a%0d%0a%3Chtml%3E TEST TEXT %3C/html%3E to start with. Then, if you see 2 different responses, and one of them is a 200, and if you see the text, you can then try whatever stuff with ...


0

It's impossible to say from your "screenshot" above, but I'd say you're not getting back 0x0D 0x0A after the location, but instead the high bytes you've sent (0x8A 0x8D), including your Set-Cookie. And you're not interpreting the returned high bytes as CRLF either, so your user agent interprets the Set-Cookie as the non-host-part of the URL. Try switching ...


3

First of all, I hope by domain.com and subdomain.domain.com you do not mean you are using HTTP in which case the cookies are highly exposed and manipulated on an attacker's will. I hope also -in case you are not using HTTPS- the services of your website are not crucial (not e-commercial, for instance). As a general good security practice, **never store ...



Top 50 recent answers are included