In this blog entry, I will summarize some commonly overlooked issues which have been affecting many web projects for the last 5 years. All of them are obvious and super predictable and could be used be script kiddies as well as by fully automated scanners and internal security checks. Let’s go!

Apache to Nginx migration configuration files disclosure. Just don’t forget that .htaccess and .htpasswd files are not usable by Nginx. Therefore it’s possible to retrieve their content by HTTP request like this: http://i-moved-from-apache-to-nginx.com/.htpasswd CDN implementation source code disclosure. The easiest way to start using the CDN is to copy all the files from the web server to a CDN. In this case, you shouldn't forget that CDNs are essentially static content servers and all the application code there will be accessible as well as images and other resources, like this: http://i-started-to-use-CDN.com/index.php Host-based authentication bypass by using X-Forwarded-For, X-Real-IP and other headers. Don’t forget that all the headers in HTTP requests are belong to attackers. If you would like to check the source of a request for belonging to intranet or localhost, double check what you are using as a source. This simple curl command can help: curl -X ‘X-Forwarded-For: 127.0.0.1’ http://i-protected-by-host-based-auth.com/ Virtual hosts abusing. I mentioned before, all the HTTP requests are belong to attackers, therefore it’s impossible to trust in anything inside it. And the HOST header is not an exception. If you have a staging.company.com virtual host available at your load balancer side, believe me, even if you don’t have a CNAME record in your DNS configuration, an attacker will find and exploit this host. This simple command can help to identify this issue: curl -X ‘HOST: staging.intranet’ http://i-like-virt-hosts/ Cross Site Scripting by insecure crossdomain.xml. A lot of web projects still have issues in this configuration file. This allows an attacker to operate with vulnerable resources by using a victim’s session, the same as with XSS vulnerabilities. Please double check all your crossdomain.xml files for the wildcard domains like this:

<allow-access-from domain="*" secure="false" />

<allow-access-from domain="youtube.*" secure="false" />

These Top 5 mistakes list is simply my own list based on the statistics collected by Wallarm over the last 5 years. I hope it was a useful read and don’t forget to automate all these checks because security means continuous defense. Enjoy!