New answers tagged

0

By putting the token in the cookie and setting that cookie HttpOnly, you can prevent access to the cookie by malicious client side script (ie, XSS) - there is no access to an HttpOnly cookie from JavaScript, the browser will protect it and handle sending the cookie only to the right origin. https://www.owasp.org/index.php/HttpOnly


0

Ok, let's start by understanding what's JWT (quoted from their website): JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. JWT.IO allows you to decode, verify and generate JWT. The goal of JWT isn't to hide data, but to prove your identity to the server. Anyone can decode the ...


1

No because the browser dont change anything in the request when sending it over https (It will only encrypt it additionally). An attack with e.g. XSS will work exactly like it would work with http. https only prevents from another type of attacks like man in the middle reading the session.


1

You are confusing CORS with SOP. CORS enables Cross Origin Resource Sharing(unless authorized by the receiver), while SOP Ensures the Data is being accessed by the Same origin that created it. So by CORS you can't access other Tab's/Frame's data, unless you can execute JavaScript there. More on CORS & SOP. There is no way you can cross SOP, unless you'...


4

If I understand this correctly, this is a lot of complexity with absolutely no security gain at all. The one thing that the whole scheme hinges upon is that an attacker stealing the cookies would not also get session_key. So you are guarding the session ID with a session key. But who guards the session key? According to you: Each user gets a random key ...


2

You should set your cookies with "httponly" and "Secure" options. That will prevent that cookies could be hijacked using Javascript and be sure SSL is used. There is a way to check if the cookies are "httponly" using session_get_cookie_params, which can increase the protection. Also enable HSTS in your web server. While it will add a little of safety, it ...


0

To simplify your question: You want to share some secret (i.e. hashed cookie or whatever) with the user. You don't what to have any user involvement in protecting the secret, i.e. no login or whatever. You want this to be save even if the computer was hacked. This is impossible. If the computer is hacked the attacker can do everything which does not ...


4

As Robert said, a jwt can be just as secure as a session if it is encrypted good. Make sure the secret you use is very unique. WARNING: There is a vulnerability with some json web token libraries that use Asymmetric keys. node-jsonwebtoken, pyjwt, namshi/jose, php-jwt or jsjwt with asymmetric keys (RS256, RS384, RS512, ES256, ES384, ES512). These are ...


5

JWT, if hashed and encrypted strongly enough, are just as secure as sessions and bring lower overhead. Just make sure to keep it small(although if you're doing anything that requires more than a few KB of storage you're probably doing something wrong...). Follow the best practices for session with JWT and you'll be fine. If you use a strong enough algorithm ...


0

I thought each browser stores their own cookies. I have tested my lab's persistence using cookies with servers behind a load balancer so I don't face the scenarios you are facing. Getting a load balancer to front your servers seem like a wise choice, you can consider. I have tried using different browsers on same client computer accessing the same site and ...


4

Depends. It is very common to ensure the session cookie integrity. One way is to create a very random (reasonable long) identifier, another way is to sign the session cookie. It is even a MUST with the stateless systems, where the cookie passes the whole user context (very popular today). So - you can have a cookie containing its signature within (such ...


0

Putting shopping cart information in the cookie, by itself, is not a security vulnerability. As long as it doesn't allow the user to do anything they aren't allowed to do, such as ordering items at different price than the real price or affecting the prices seen by other users/sellers. A user being able to mess with their own displays is not a security ...


0

Tampering with it does not affect the operations. There are 3 possible explanations: 1) The information in the cookies is redundant 2) you've not yet found the right combination of circumstances where the content of the cookie does affect the function 3) it did have an impact but you did not observe it Clearly 2 above would mean that there is a ...


0

As you already used the words "sensitive information", it is not recommended to pass the info in cookies. Also, if secure and http-only attributes are not set, it is easy for an attacker to read this data. So the question you should ask, "do I want someone to access this information?" If the answer is strict no, then don't pass it.


3

Putting actual information into cookies, as opposed to just storing a session ID and keeping the rest of the information server side can (but does not have to) be problematic. There are two pitfalls you want to avoid: Trusting information in the cookie without server side validation, e.g. accepting a total price of $0.01 just because the cookie says so. ...


1

If you ensure your token contains enough entropy (> 128 bits), then you shouldn't need to check user ID as well. I would also store the token hashed within your database using something at least as secure as SHA-2, that way if your remember-me table is compromised in any way, an attacker can't hijack sessions. The cookie set on the client should be the raw ...


2

As long as you have chosen a sufficiently large CSPRNG for the token, checking it should be sufficient. Somewhere in the 128 to 256 bit size should be sufficient. You don't mention where you're storing the token in the user's browser. Cookies are typically used for this. You should have the Secure and HttpOnly setting on the cookie. Basically, you should ...


2

You can not validate the used Browser and Machine Name (dont know at all how to get it), because all of that is send by the client, so an attacker can send what he want. The security relies only on the session id, a long, random and unique id generated on the server and stored in the cookie. You should give all the different machines where the user logs on ...


3

Maybe you should think about threat models instead of coming up with solutions to fake problems. What's the threat model here? That I copy my own session cookie to another computer? Not a real threat. Worried about javascript stealing cookies? Use httponly cookies Worried about malware stealing your cookies? You're already screwed


1

First, control which scripts are loaded The most important reason to block ads is to protect yourself from malicious, dangerous and incompetent code delivered through these ads. Accordingly, script blocking is a far better method than ad blocking (alone). Once you do that, you can leverage that tool for fine-grained control. Let's first assume that you ...


1

The way these scripts work is by trying to detect if a HTML element that is supposed to be holding the ad exists or is empty since adblocks methods are to remove the content from the page. Adblocker's don't have much to do about it since they remove the elements/empty them which can be easily detect by Javascript with some code as the following: if (...



Top 50 recent answers are included