Sunday, December 4, 2016

twelve "low hanging fruits" application owners can check by themselves before ordering an penetration test.


The following 12 common security issues can easy be checked by application owners themselve before ordering a penetration test. This will not substitute the need of a penetration test but it can save time and money.




1) SSL enforced.
Check if each request is redirected from HTTP to HTTPs.

2) HSTS Policy
HTTP Header which declares that web browsers should only interact with it using secure HTTPS connections.

3) SSLLABS Rating
Check how SSLLABS rates the security of your applications SSL/TLS setup
https://www.ssllabs.com/ssltest/ (DO NOT FORGET to check "do not show results on boad")
Applications handling sensitive data like credentials should have a minimum Rating of A-
Follow the suggestions for each finding.
Guides for Apache and NGINX to secure SSL

4) Server component disclosure
Check which http headers your server responds. Typically Server headers like "X-Powered-By" and "Server" disclose detail components and versions used by your application.
You can check online with pages like http://web-sniffer.net/ the server headers of your application.
Google how disable your specific header. X-Powered-by in PHP can be disabled by setting "expose_php = Off" in php.ini.
Apache Server header can be set to "Server: Apache" by setting "ServerTokens Prod" in httpd.conf.

5) Service Port's open
Check which of your service allow to be connected direct from internet.
You can do an online port scan with https://pentest-tools.com/network-vulnerability-scanning/tcp-port-scanner-online-nmap for example.
Ideal case is that only port 80 (HTTP) and 443 (HTTPS) are public available. All others should be restricted.
If there is the need to keep Port 22 (SSH) open for administration ensure that only certificate based  authentication is allowed.
Database ports like MYSQL 3306 must be not public available.

6) Cookie Security
Check if at least your session cookie is set to SECURE, HTTP-ONLY and expires at end of session.
That can easily checked with browser plugins like Cookie Manager in Firefox

7) Userid existence disclosure
If your application is providing an authentication, check if wrong username and wrong password always responds with the same error message. Otherwise this will disclose the existence of a user account.
If you use the email address as username, ensure that also forgot password and self-registration does not disclose the account existence. The “forgot password “service should always respond with the same message like "if your account exists we send you instructions how to reset your password" or similar like that. The registration should be protected with a captcha before showing that the email address is already in use.

8) User lockout Strategy
After several negative attempts to sign on with a specific account the application should block the account for a specified time period (approximately 10 minutes) or request a captcha, to avoid the possibility of password brute force attacks.

9) Session Fixation
If the logon is successful as response of the authentication the value of the session cookie must be changed. The session must be destroyed at client and server site as response of the successful logout.

10) Frameable response
Sending the proper X-Frame-Options HTTP header instructs the browser to not allow framing from other domains to avoid Clickjacking attacks.
How to set this header for Apache and NGINX

11) Error handling
Check the response of your error pages for 404 (not found) and 403 (forbidden). Ideal case would be that both shows the same custom error page.

12) Open directory listings
Access a folder of your web application and ensure that the directory listing is not shown.
How to disable for Apache and NGINX
--