New answers tagged

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

Conserning POST and GET A link allows GET request when it is clicked. A form allows GET or POST requests when submitted. All GET requests that can be done with a form can also be done with a link and vice versa, so the extra functionality that the form allows is the POST requests. Asuming people stick to the intentions of the HTTP verbs, a POST requests ...


2

A form is more dangerous because it hides more stuff from the user than a simple link and can do different things. automatically removes any script tags, click events and basically any Javascript I assume that means that it also removes javascript:... links. So the only links an attacker can produce are simple GET requests, which amongst others, are ...


7

Yes, it is. By how much, and if it would be ok for you to allow forms depends on your specific situation. CSRF with referer checks If your CSRF protection depends on referer checks, not on a token, allowing forms means that you would be vulnerable to CSRF. As you disallow scripts, a victim would still need to actually click the form, but that can be ...


1

describes an attack on http response protocol ... the attack is called CRIME ... html files have secret information? CRIME is not about detecting secrets in the HTML file (which gets sent as the response from the server to the client) but about detecting the secrets in the request (sent from the browser to the server). Or as it is described in the ...


0

If your looking to completely eliminate chances of being vulnerable to XSS attacks, add this to your PHP script. When you grab the user input and insert into a variable, like this: $input = $_POST['input'];, instead of that (which is 100% vulnerable) go: $input = htmlspecialchars($_POST['input']);. Or, you can also go: htmlentities($input = ...



Top 50 recent answers are included