To enable attack monitoring, the specific web.config entry depends upon which IIS Managed Pipeline Mode is enabled on your website. Click an option below for the appropriate instructions.
In IIS 7 and beyond, each application pool uses one of two .NET integration modes for running ASP.NET applications: "Integrated" or "Classic".
Integrated mode allows ASP.NET modules to participate in IIS request processing, regardless of the type of resource requested.
With classic mode (IIS 6), requests are initially processed through IIS modules, and then ASP.NET requests are separately processed via the aspnet_isapi.dll.
Add the highlighted entry to the configuration/system.web/httpModules section of your web.config file, as illustrated in the snapshot below. If your web.config file doesn't have an <httpModules> section within <system.web>, then add it along with the highlighted portion.
<add name="Westination.SQLInjectionShield" type="Westination.Web.SQLInjectionShield"/>
Add the highlighted entry to the configuration/system.webServer/modules section of your web.config file, as illustrated in the snapshot below. If your web.config file doesn't have a <modules> section within <system.webServer>, then add it along with the highlighted portion.
<add name="Westination.SQLInjectionShield" type="Westination.Web.SQLInjectionShield" preCondition="integratedMode,managedHandler"/>
I Don't know or I'm Unsure
After uploading the unzipped folders to the root of your website, navigate to:
The resulting webpage, hosted on your website, will tell you which managed pipeline mode your website is using. It has a Configuration Guide that is tailored to your website, so you can continue the installation process from there, confident that you have made the correct configuration selection.
How to Toggle On & Off
Commenting out or removing the highlighted element within the <httpModules> or <modules> section (as defined in your above choice), disables attack monitoring. In this fashion, you can quickly toggle between enabled and disabled states, without having to remove the uploaded files or having to modify any other web.config entries.
How Do I know It's Working?
The only way to know for sure is to attack yourself. Append the following query string to the end of a page link on your website.
?test=1 or null is null
Example: http://your-website/default.aspx?test=1 or null is null
If installed correctly, you should see a corresponding "FailureAudit.html" event file within the ./Westination/SQLInjectionShield/EventLog/ folder. If you enabled email notifications (next tab), then you should receive a corresponding email alert as well.
In case you're wondering, the term "FailureAudit" means that the request failed the safety audit.
Attack events are logged to the ./Westination/SQLInjectionShield/EventLog/ folder.
SQL Injection Shield™ will also send reports, via email, to the recipient(s) defined in the configuration/appSettings section highlighted below. In order to receive attack notification emails, it is important that your outgoing mail server is correctly defined within the system.net/mailSettings section, as illustrated below.
To enable email notifications, add the following highlighted entries to your web.config file.
<add key="Westination.SQLInjectionShield.Email.Recipients" value="email@your-domain;next.email@your-domain"/>
<!-- smtp from = the address that will appear as the sender of the email. -->
<!-- network host = your outgoing SMTP mail server. -->
<network host="your-mail-server" port="25" userName="" password=""/>
If you're not receiving emails, then check the EventLog folder. If the event is logged there, then there is a problem with the email settings defined above.
|1.||Does the specified mail server allow sending from your website?
|2.||Is the specified port correct?
|3.||Is the specified username and password correct?
|4.||If your web server is also your mail server, then try specifying 127.0.0.1 as your host.
|5.||Did you check your spam folder?
By default, SQL Injection Shield™ monitors all the standard ASP.Net page types that receive and process input (.aspx .ashx .asmx, etc.) However, there may be cases when one would want to either extend or override the default monitoring. For example:
What if you have a custom page handler installed on your website that accepts input from non-standard pages, and you want SQL Injection Shield™ to monitor those as well?
Or, what if you need to exclude a page or folder from being monitored for some reason? E.g. you have a secure webpage that allows privileged employees to execute ad-hoc SQL queries to your database.
The web.config entries, illustrated below, are based on the following example scenarios.
|1.||You have installed a custom page handler that enables your website to respond to requests for pages with a .custom extension, and you want SQL Injection Shield™ to monitor and protect your .custom pages.
|2.||You have a secure folder on your website, named http://your-website/secure/ad-hoc/, which allows privileged employees to execute ad-hoc SQL queries to your database, and you want to disable monitoring on pages within that folder.
<add key="Westination.SQLInjectionShield.PageProtection.Additions" value="*.custom"/>
<add key="Westination.SQLInjectionShield.PageProtection.Exclusions" value="/secure/ad-hoc/*"/>
The * character is a wildcard symbol, therefore the extensions .custom1 and .custom2 can be represented by a single *.custom* entry.
If you have multiple additions or exclusions, separate them with the | character. For example: *.abc|*.xyz