New answers tagged

0

" When a server supporting the Token Binding protocol receives a bound token, the server compares the TLS Token Binding ID in the security token with the TLS Token Binding ID established with the client. If the bound token came from a TLS connection without a Token Binding, or if the IDs don't match, the token is discarded." draft The problem ...


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

If you've always used that Facebook account through Tor, and never through your normal connection, and the Facebook account is for an anonymous identity rather than your real identity and you never make any references using your real identity to your alter ego and vice versa, and you never login, then using Facebook over Tor does not necessarily compromise ...


0

For making cross-site requests, standard practice is to authenticate a user's credentials after the first request. If your users are going to make multiple requests to the web app in a single session, you can then send back a CSRF token and store it in the user's cookie, which is then sent along with every subsequent request and authenticated by the web app ...


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 ...


6

The reason you see that message is Article 5(3) of Directive 2002/58/EC, as amended by Directive 2009/136/EC, according to which users have to give consent for the storing of information (read cookies) or retrieval of information already stored. Some cookies are exempt from this rule, namely when the cookie is needed for carrying your data over the ...


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 ...


-2

SSLStrip+ works without deleting browser data too. The script needs a fake DNS server to work, in fact modifying DNS queries you have an huge possibility to bypass HSTS. So you don't need to clear your data. Also HSTS depends on the HTTP request header, so for example when you navigate to Google you make a GET request and the response header says to the ...


0

I have tried hard on same kind of bug you are talking about. But the same problem that I'm facing is, You can easily inject a cookie or Set-Cookie but Can't exploit further such as XSS, Content Injection etc. You can inject HTML content on 302 Redirection page but It doesn't make sense because very next you will get redirected to page. In this case only ...



Top 50 recent answers are included