New answers tagged

2

First, a definition from Chrome: Same-site cookies (née "First-Party-Only" (née "First-Party")) allow servers to mitigate the risk of CSRF and information leakage attacks by asserting that a particular cookie should only be sent with requests initiated from the same registrable domain. So what does this protect against? CSRF? Same-site cookies can ...


1

I don't believe this would provide any more protection then the normal double submit cookies. If an attacker can overwrite one cookie using an unsecured (https) subdomain, they could just as easily overwrite 2 cookies. The attacker in the senario would get a legitimate token and signed token value, they would embed both of those in the request, and write ...


1

The problem with naive double submit is that if the attacker could insert an attacker controlled cookie he could also set the CSRF token to this cookie and this way defeat the CSRF protection - because token and cookie match. This can be defeated if the attacker is not able to create a CSRF token and guess the matching verification cookie. This can be ...


0

It's simple =) In no-proxy case you're tracing all the redirects yourself, so it's no problem to handle it. A proxy can be tricky as the proxy itself(not Tor case, but there are programs that behave a bit weird), so the proxy component for your language can be. Especially it happens frequently with HTTP and HTTPS proxies. Use a tcpdump - it will show you the ...


0

how does it differentiate the a normal request from a request through a proxy? Proxy detection is usually based on IP addresses. That is particularly easy for Tor, because the IPs of relay nodes are public. From Instagram's perspective it makes sense to block proxies as a mean to enforce rate limis for their API endpoints. Besides that, there is no ...


1

One method is to use a private browsing window or Chrome Incognito session as these new browser instances do not share cookies with the rest of the browser, so therefore protection against CSRF is offered. Bear in mind that these sessions do share cookies with each other, so it is recommended to close all private/incognito windows and relaunch when you are ...


4

Maybe use two browsers, one for those account, and another one for browsing? This is a probably the best idea since it offers the most separation. This way classical session cookies will not be shared between sites, although a sharing of Silverlight and maybe Java or Flash based session ids might still happen. In most cases it will probably already be ...


0

Traditionally the web administration service for most routers is bound to the LAN facing interface with at least basic HTTP auth. So the is strange for Motorola. So they must have either too small a memory footprint so they went with a HTTP server that does not do auth or they went with a language that has a HTTP web server module without HTTP auth built in ...


2

functions such as reboot and factory reset ... why would a modern browser allow internal resources to be loaded from an external page Most of today's routers and other networked devices will be administrated through a web interface. This means that there is some web server with a web application running on the device and the user is using the browser to ...


2

Shouldn't it be possible to use referrer checks as CSRF protection which work even if an XSS vulnerability exists? Nope. If you are injected script, you can create a <form> pointing at the same origin, include a purloined CSRF token, and submit it with the expected Referer header. (Also referrer checks are problematic in general of course, and ...


3

No, I don't think so. It could be circumvented by creating an iframe with display: none, containing the page add-users.php. Then all the attacker has to do is to fill in the form fields and submit the form with JavaScript, and the attacker has successfully added a user without the victim's consent or knowledge. Checking the referer header would not stop ...


1

I've read that JWT tokens shouldn't be stored in localStroage because XSS attacks can read them. True. If you store information in your JWT and don't want an attacker to read it via XSS, storing them in a httpOnly cookie is a good idea. The proposed solution is to store JWT tokens in HTTPOnly cookies and use CSRF w/ double-submit cookies. I ...



Top 50 recent answers are included