Tag Info

Hot answers tagged

6

First off: This is absolutely the wrong way to solve CSRF problems. CSRF vulnerabilities are a problem in your site, not in the browser. Blacklisting certain browsers is not going to solve your CSRF vulnerabilities. CSRF is not browser-specific and cannot be prevented through browser blacklisting. Detecting browser versions: There are various ways to ...


5

Also, why is whitelist approach better than blacklist approach as mentioned by OWASP. Why not just block a handfull of characters used in XSS like < , > , etc Blacklists are static in the sense, they prevent 'known bad' from happening. The problem with this is, there are new attack vectors found everyday and you would need to constantly update ...


5

That's why the character class [[:alnum:]] exists; it includes the characters which are considered valid alphanumerics in the currently active locale. Of course, that doesn't work well on a web server in the US when someone in Egypt is attempting to provide input through a form - and it doesn't work with punctuation. But it also doesn't include spaces, and ...


3

It is not just a block of handful characters that you need to blacklist. In security we go by this dogma: "There are things we know that we know. There are known unknowns. That is to say there are things that we now know we don't know. But there are also unknown unknowns. There are things we do not know we don't know." Blacklist might help you ...


3

I think you might have rejected ESAPI too quickly. To defend against XSS, I recommend you do output escaping: any place where you insert data dynamically into an HTML document, escape the data (in a way suitable for that parse context). ESAPI provides libraries for the escaping and is very useful. This does not involve "changing your input". For more, ...


2

If the customer is as security aware as the question imply's then they will understand that the only reliable way to perform the task would be to whitelist traffic to the IP address range for Amazon ELB service. If the worry is that this would allow other websites using the same service external access then a proxy server or secondary firewall would be ...


2

There are two things I can think of, neither fits the bill perfectly, and there's some assembly required. squid with sslBump and the SSL Server Certificate Validator This is basically an MITM SSL proxy configuration, and you get to provide an external "helper" that augments normal verification. Stumbling blocks include certificate trust and managing your ...


2

This method is sufficient to protect against Apache serving this directory, but a configuration error may disable this: If your main Apache configuration contains AllowOverride None (or similar), then .htaccess files are ignored. Thus your IP whitelist does not apply. Depending on the hostname or directory, different configuration might be set. If you have ...


1

IP spoofing only works for incoming, UDP traffic. If you need the return trip to work, network layer IP spoofing doesn't work any more. While white-listing is a good defence in depth strategy and mitigates against many attack vectors, some attack vectors still remain, like MITM attack. The traffic between the two servers can still be intercepted and ...


1

As long as there are not any other services that are vulnerable to exploit it should be sufficient. I would personally recommend placing a firewall between server 1 and server 2 to ensure that only server 1 can communicate with server 2, but if that isn't possible, a whitelist and locking down services on server 2 is your next best bet.


1

You can filter by certificate using an SSL-terminating proxy, as Mr Spuratic explains well. However, turning an SSL pass-through proxy to an SSL-terminating proxy is quite a big deal, and not something you would do purely for the motivation you outline. Your best pragmatic option is to filter by host name.


1

I would recommend spending a little effort writing a parser for the arithmetic expressions in the input rather than dynamically executing it as Lua code. Even if you haven't got a third party parsing library available, it's not too difficult to write a lexer that splits up a string in relevant symbols, and then traversing those with a state-machine or ...


1

Hashing is not the right cryptographic tool; what you want is a MAC. Your point is that you want some emails to go through antispam filters, but since you do not want spammers to use the same path (obviously), you are ready to enforce the use of an extra field in the email, which would contain some authenticating value that, hopefully, spammers cannot ...


1

I did some research on your question and found the word unsantaized for your question. When this word is linked to policy it makes more sense, because this is where you define what is acceptable and what input is not acceptable. Also , depending upon the application design an unsantaized may get rejected.No direct logic should apply to a data that is in ...


1

Greylisting is used in the context of an antispam technique for emails. It somehow uses this terminology: Whitelist: people who are allowed in, unconditionally. Blacklist: people who are rejected, whatever they claim. Greylist: the other people, who are temporarily rejected but will be whitelisted (i.e. allowed to enter) if they bother to come back later, ...


1

do input filtering No, no, no. By all means do in validation - accept or reject the input based on rules. Don't try to change the input data. If the interface between your webserver and your application language allows content through which compromises you application language then there's something very, very wrong. Certainly you can't handle this ...



Only top voted, non community-wiki answers of a minimum length are eligible