These are mainly based around ASP.NET/IIS – but the same principles can be applied everywhere.
These are just a few that I’ve seen highlighted a lot in pen tests of late.
Nothing is going to make you 100% secure but remember – defence in depth. Lots of defences adds up.
I may get some others written up some time.
(HTML/URL) Encode everything
Why
This helps prevent Cross Site Scripting (XSS) attacks. XSS attacks occur when user input (or other data) is displayed on the browser. The attacker puts javascript in the input and this is then executed by the browser.
Examples
sending the user a link with a query string which contains a value that is displayed on the target page – look at google and you’ll see the search is in the url and displayed on the browser. (Reflected XSS).
Putting data in to the system that is displayed on someone elses browser (e.g. facebook page) (Stored XSS). For a great example of this watch this watch https://www.youtube.com/watch?v=EYMGAoIx8yk&feature=youtu.be FROM 8:30
How?
- Http(s) content type MUST be utf-8 – for asp.net this can be specified in the master page / web.config.
- In ASP.NET (>4) Use the <%#:, <%:, <%=: to ensure databound or other expressions are html encoded (https://www.owasp.org/index.php/ASP.NET_Output_Encoding).
- Use ASP.NET controls that automatically html encode/decode. See - https://msdn.microsoft.com/en-us/library/ms178270%28v=VS.100%29.aspx for an indication of which controls automatically html encode output. In particular note the Label Control does not automatically encode.
- Razor automatically html encodes (https://docs.microsoft.com/en-us/aspnet/web-pages/overview/ui-layouts-and-themes/4-working-with-forms) – think carefully before overriding. (You might have actual html that you want to display as html).
Use strongly typed parameterised queries (that’s stored procs or EF).
Why
To mitigate against SQL injection attacks.
Parameterised queries (and stored procs) should treat the input as input – not build sql strings from them so cannot be manipulated as easily.
How?
Use an ORM (Entity Framework) AND DO NOT GENERATE SQL ON THE FLY IN YOUR CODE.
Use strongly typed stored procedures and DO NOT GENERATE SQL ON THE FLY IN YOUR SQL.
Combine this with
- least privilege (execute on stored procs or data reader/writer on appropriate tables for EF) – note SPROCS allow a more minimal access as an attaker owning the applications connection can still not read whole tables but needs to go through stored procs.
- A defence mechanism for preventing developers from still generating sql on the fly.
- e.g. for stored procs review them all.
EF does not particularly encourage sql on the fly but none the less be aware application developers now have a connection available that can do data reader/writer functions. I have seen this result in a successful attack – not surprisingly on the last (hastily implemented) CR implementation.
Implement some secure configuration/hardening
These are some simple hardening recommendations – may not do much but will not make you less secure!
Why?
- Your application and server (IIS) etc. uses technologies. These may have known vulnerabilities. Advertising the technologies is the same as advertising the weaknesses. Security by obscurity is not security but giving attackers a list of sites to attack when a vulnerability is published is dumb.
- Reduce the attack surface area.
How?
•Disclosure of server type / Disclosure of technology
* For azure - (https://azure.microsoft.com/en-us/blog/removing-standard-server-headers-on-windows-azure-web-sites/) – this should work in IIS too – but depends on later frameworks.
For IIS - https://www.saotn.org/remove-iis-server-version-http-response-header/
- Block unwanted request verbs - for a web site you probably only need GET and POST. For rest you might need PUT and DELETE too (if your really rest). https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/verbs/ Personally, of course, I prefer white-listing
<configuration>
<system.webServer>
<security>
<requestFiltering>
<verbs
allowUnlisted="false"
>
<add verb="GET" allowed="true" />
<add verb="POST" allowed="true" /></verbs>
</requestFiltering>
</security>
</system.webServer>
</configuration>
See - https://docs.microsoft.com/en-us/iis/manage/configuring-security/use-request-filtering
- Set custom errors RemotOnly (https://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.100).aspx)
- Set debug=false.
Use least privilege database access (or any other access!)
Why?
Defence in depth – if someone owns your web server or another defence (e.g. sql injection) fails – limits the damage can be done.
How
- Don’t use dbowner/sa
- Do use separate account for applications with privilege to execute stored procs (GRANT EXEC ON proc TO user) or (if using EF) data reader/writer as required on specific tables.
- Do this from the beginning in all your environments so you don’t hit all the issues late in your dev cycle.
Configure your security headers and cookies
See - https://securityheaders.com/
Why?
Modern browsers are adding additional protection against vulnerabilities – xss, disclosure.
How?
See https://securityheaders.com/
If your are https (and you should be)
Enable hsts
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Strict-Transport-Security" value="max-age=31536000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Set requires SSL on all your cookies - <httpCookies requireSSL="true" />
(and your forms auth config too if you have it).
X-Frame-Options – do you want your pages to be embedded in another site. Allowing this facilitates an attacker making a fake site.
X-XSS-Protection – tells the browser to turn on xss filters.
X-Content-Type-Options – stops content type sniffing
Content Security Policy – allows you to list where your page downloads from so you can protect from downloading malicious code.
Referrer Policy – limits the “Referrer” information in http requests. For example, if you download fonts from google do you want google to be able to track people on your site through the referrer header. Remember you may letting a third party know the IP (personal information under GDPR) the activity on your site.
