With the average insurance claim following a ransomware attack now in excess of $1M, no organisation can afford to be complacent.
In our Penetration Testing and Vulnerability Assessment work we frequently find vulnerabilities to preventable attacks. Some problems require significant expertise and skill to identify and address. This is the value of the service we provide.
However, we also find problems that with a little skill your team could, and probably should, have addressed. This can cause delays while the exploits are fixed and the code/systems are retested.
So if you don't want to pay the purveyors of malware a million $+, and you want to save money on your penetration testing budget, read on...
Here's a simple checklist your coders can use:
Implement a field validation library and call it at every entry point. Validation should include maximum field lengths, number ranges, and string formats & character subsets.
Ensure that any client-side validation is also done server-side. Client-side validation is for user experience, server-side validation is for security.
Only pass essential data from server to client. Don't rely on client-side filtering.
Implement an authorisation-checking library and call it at every entry point. Call this even before attempting validation.
In your test plan, ensure that you test every page with each type of user. So if a page can be accessed by an unauthenticated user, by an authenticated but unprivileged user, and by an administrator then the page needs to be tested 3 times.
Ensure that your site has been functionally tested before being penetration tested.
Ensure that your development team is confident that there are no security problems before starting the pen testing process. Penetration testing is not for testing discoverability of known security problems!
Ensure that any reverse proxies, gateways or caches are configured to treat HTTP headers the same as the application (origin) server. In particular beware of Content-Type and Transfer-Encoding differences.
Ensure that you are using the latest versions of any third-party software (libraries, applications and operating systems). In particular focus on user-facing systems.
Ensure that your user-facing HTTPS systems are configured to use secure cryptography protocols.
Avoid string concatenation for constructing machine-readable strings. Instead use a specialised library designed to apply the relevant escaping (or avoid string-building altogether). This applies especially to:
file and directory names
database query strings
HTML, CSS or Javascript fragments
In the browser, avoid DOM manipulation if possible. In particular avoid using user-controlled variables like window.location to set any other variables.
Ensure that crash stack traces are never sent to the client.
It goes without saying that doing these things alone will not stop a determined attacker. Nor do they negate the need for periodic testing of your site by competent professionals.
But it will make the hacker's job a lot harder and you'll get much more value out of your penetration test.
Comments