74

Country-based blocking is usually put in place as a result of some organisational policy whose intention is indeed to "block hackers". This sort of things fail on three points: Such a policy assumes that malicious people can be categorized by nationality. This is old-style, World-War-I type of thinking. Geographical position is immaterial for computers; a ...


64

The sniffing problem is about "confidentiality", which whitelisting does not cover, as the traffic can be intercepted and read. The MitM problem is about "authenticity", which whitelisting does not cover either, as an intercepted packet can be modified without evidence of tampering. I assume the whitelisting uses IP addresses, which can be arbitrarily ...


26

In my case, our expected customers come from predictable countries, and so to limit the "threat surface", other countries are blocked. This has limited value as any determined person can do what you did and simply re-route their traffic. The side benefit, though, is that the countries we permit are those with stringent cyber-laws and we can get law ...


13

If the data is unencrypted, anyone sniffing the packets between your server and their server can see it. A whitelist only lets their server verify that the source of the data. It doesn't assure that no one sniffed it during transfer, or that it wasn't intercepted and manipulated at any point during the process. In short, encrypt the data, keep the whitelist ...


8

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


7

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


7

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


7

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


5

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


5

Assuming you're asking this in the context of Web Development... You can detect appropriate character sets with simple regex validation. However, you may also be falling victim to security theater: input sanitation is not the answer. If you are trying to validate for specific locales, and you don't want to accept any other locales, you can choose specific ...


5

I think Software Restriction Policies are what you're looking for. It is basically the predecessor to Applocker, and it is still supported for application whitelisting or blacklisting. It isn't as powerful or comprehensive as Applocker, but on Professional versions without Applocker, it can get the job done. See Spiceworks Guide on Deployment and Microsoft ...


5

Assuming that your side initiates every communication, then yes, blocking every connection to your machine from IP addresses you didn't connect to is a good idea. But note that this is firewall basics. Most client-side firewalls don't allow any incoming connections initiated from a remote machine unless you specificallly allow them. They do more than you ...


4

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


4

Our answer is that for a truly international application, on general input such as people's names, you should accept everything and encode it at display time. Admittedly that (to some extent) passes the problem down to the guy writing the Encode algorithm. However, if you have an input that is a specific thing, such as a vehicle number plate, or a business ...


4

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


4

I'm not sure if this is really an information security question per se or more of one about general networking; but here goes: If you have a number of dynamic IPs connecting to a client that requires whitelisting, this will lead to constantly having to ping the client to update the ACLs to allow IPs as they change. While on modern residential connections ...


4

If you whitelist a directory, then sure, any malware in that directory can run. That's why you don't whitelist directories. Instead, you whitelist programs, and you take precautions to ensure those progrms aren't modified. For example, instead of whitelisting "c:\Program Files\Internet Explorer", you whitelist "c:\Program Files\Internet Explorer\iexplore....


4

When talking about security (in general), it is important to think about what problems you are attempting to solve, and what tools you are using to solve them. These have to align. If the problem you are attempting to solve is general attacks from the internet, then whitelisting may be a useful tool - to overcome whitelisting, you have to be somewhere on ...


4

TLDR: Nope, and if you think you need that, you're probably doing something wrong. There is literally no possible way to prevent non-browser access to anything that is also exposed to browsers. As far as a server is concerned, a web browser is just a program that sends and receives HTTP (and related protocols) traffic. That's it. You can do that using curl, ...


4

The problem is when user-specified HTML is included together with your own HTML and application logic on the same page. It is common that the application logic depends on the content or location of specific elements inside the HTML which are selected based on id or class name. If you allow the user to specify any class name an attacker might be able to ...


4

Security benefits: If an attacker had stole your client credentials then he or she will have an additional trouble connecting to your server. Basically the intruder will have to connect from one of your client networks to have whitelisted IP address. An example of such a case: client looses his laptop or some one copies his hardrive or stole his flashdrive. ...


3

Sudo blocks environment variables that might be bash function definitions (2004-11-11 env.c: strip exported bash functions from the environment), even if the variable name is whitelisted. That's why sudo isn't included in the list of common attack vectors for Shellshock. A bash script invoked by su to a restricted account can be an attack vector. But there ...


3

It's true, if a hacker would like to get access to your page, it will not help, he can simply use a vpn or proxy. But if you think about all the bots out there which attack every page they find to test exploits and/or passwords, you will be able to block a lot of them. This will also help you against ddos attacks, if you block every country except the one ...


3

do input filtering No, no, no. By all means do input 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 kind ...


3

If you are getting your network assessed for the first time I would suggest giving the pentesters complete access. You will get a report that is comprehensive which would include all the vulnerabilities that exists in your assets. This will give you the complete understanding to plan upgrading the security of your network. Moreover, during a pentest, the ...


3

tl;dr: different things, both useful for different scenarios, IP whitelisting is not a bad sign You are indeed comparing apples and oranges. IP-based filtering happens at the network layer of the OSI model, whereas certificate validation happens on the transport (and/or application) layer. Allowing access only to/from specific IP addresses reduces the ...


3

MAC Whitelisting as well as Blacklisting are pretty much useless for security. Your strong WPA/2 passphrase however is great (if WPS isn't enabled). As kub0x said, the Layer 2 info isn't encrypted. MAC addresses are fully visible: If you have a laptop or a wifi card, install or VM a linux distro and fire up the aircrack suite. With Airodump-ng, you can see ...


3

OSI layers do not care where the check happens, but at which layer the information used in the check reside. If the check is doing whitelisting by IP address only it does not matter where the check is configured, because the decision is always purely based on the IP address, i.e. OSI layer 3. But, depending on the setup and the validation code the check ...


3

In depth defense recommends that you put multiple defense lines to protect your system against as much attack vectors as possible. What you describe sounds good because you try hard to control what will be executed on your system. But IMHO, antiviruses are specialized pieces of software that research downloads and file systems for known signatures, ...


3

From a very basic perspective, yes, being onsite is safer. The key reason being that there is a smaller attack surface. If you are connecting in via a VPN, there are numerous additional items which could be attacked (yes, in a perfect world, you would have a secure VPN that couldn't be broken/hacked/misconfigured, but this world is definitely not perfect) ...


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