How to Harden the Security of Your .NET Website

Outline
• About Ashish Prasad
• Website Security
• Security Questions to ask your Vendor
• OWASP: Concepts and Top 10
• Understanding Encryption
• High-Level Architecture of a .NET Website
• Security Best Practices for IIS 8
• Regular Checkups
• How to spot CSRF
• How to spot XSS
• .NET Website Security Resources

About Ashish Prasad
• Director of Engineering at DNN Corp.
• Co-Author of DNN Professional 7 Book
• Microsoft MVP
• CISSP
› Certified Information Systems Security
Professional
• Twitter: @ashishprasad | @DNNCorp

Website Security
Website
Security
Infrastructure Security
- Firewall,
- Antivirus
- OS Patching
Application Security
- XSS
- CSRF
- Injection

Security Questions to Ask Your Vendor
• Do you issue Security Bulletins with your release?
› For DNN Corp – Yes.
http://www.dnnsoftware.com/community/security/security-center
• How often do you test for security in your product?
› For DNN Corp – Every release and all the time
• Do you have incidence reporting system in place for customers?
› For DNN Corp – Yes. Email: security@dnnsoftware.com
• Do you have a tool to check security
› For DNN Corp – Yes. http://www.dnnsoftware.com/community-
blog/cid/155364/updates-to-security-analyzer-tool

OWASP
OWASP is an open community dedicated to enabling organizations
to conceive, develop, acquire, operate, and maintain applications
that can be trusted. All of the OWASP tools, documents, forums,
and chapters are free and open to anyone interested in improving
application security. We advocate approaching
application security as a people, process,
and technology problem because the most effective
approaches to application security include improvements in all of
these areas.
For further information on OWASP: https://www.owasp.org/index.php/About_OWASP

The OWASP Top 10
The OWASP Top Ten represents a broad
consensus about what the most critical web
application security flaws are.
•First done in 2010
•Second done in 2013 (current)
•Currently working on the latest version, expected
in 2016 or 2017

The OWASP Top 10
• A1-Injection
• A2-Broken Authentication and Session Management
• A3-Cross-Site Scripting (XSS)
• A4-Insecure Direct Object References
• A5-Security Misconfiguration
• A6-Sensitive Data Exposure
• A7-Missing Function Level Access Control
• A8-Cross-Site Request Forgery (CSRF)
• A9-Using Components with Known Vulnerabilities
• A10-Unvalidated Redirects and Forwards
For more information: https://www.owasp.org/index.php/Top_10_2013-Table_of_Contents

OWASP > A1: Injection
Injection flaws, such as SQL,
OS and LDAP injection occur
when untrusted data is sent to
an interpreter as part of a
command or query.
The attacker’s hostile data can
trick the interpreter into
executing unintended
commands or accessing data
without proper authorization.
Note: Images and descriptions for these Top 10 slides courtesy of the OWASP website:
https://www.owasp.org/index.php/Top_10_2013-Top_10

OWASP > A2: Broken Authentication and Session Management
Application functions related
to authentication and session
management are often not
implemented correctly.
This allows attackers to
compromise passwords,
keys, or session tokens, or to
exploit other implementation
flaws to assume other users’
identities.

OWASP > A3: Cross-Site Scripting (XSS)
XSS flaws occur
whenever an application
takes untrusted data and
sends it to a web browser
without proper validation
or escaping.
XSS allows attackers to
execute scripts in the
victim’s browser, which
can hijack user sessions,
deface web sites, or
redirect the user to
malicious sites.

OWASP > A4: Insecure Direct Object References
A direct object reference
occurs when a
developer exposes a
reference to an internal
implementation object,
such as a file, directory,
or database key.
Without an access
control check or other
protection, attackers can
manipulate these
references to access
unauthorized data.

OWASP > A5: Security Misconfiguration
Good security requires
having a secure
configuration defined and
deployed for the
application, frameworks,
application server, web
server, database server,
and platform.
Secure settings should be
defined, implemented, and
maintained, as defaults are
often insecure.
Additionally, software
should be kept up to date.

OWASP > A6: Sensitive Data Exposure
Many web applications do
not properly protect sensitive
data, such as credit cards,
tax IDs, and authentication
credentials.
Attackers may steal or
modify such weakly
protected data to conduct
credit card fraud, identity
theft, or other crimes.
Sensitive data deserves
extra protection, such as
encryption at rest or in
transit, as well as special
precautions when
exchanged with the browser.

OWASP > A7: Missing Function Level Access Control
Most web applications verify
function level access rights
before making that
functionality visible in the UI.
However, applications need
to perform the same access
control checks on the server
when each function is
accessed.
If requests are not verified,
attackers will be able to forge
requests in order to access
functionality without proper
authorization.

OWASP > A8: Cross-Site Request Forgery (CSRF)
A CSRF attack forces a
logged-on victim’s
browser to send a forged
HTTP request, including
the victim’s session cookie
and any other
automatically included
authentication information,
to a vulnerable web
application.
This allows the attacker to
force the victim’s browser
to generate requests the
vulnerable application
thinks are legitimate
requests from the victim.

OWASP > A9: Using Components with Known Vulnerabilities
Components, such as
libraries, frameworks, and
other software modules,
almost always run with full
privileges.
If a vulnerable component is
exploited, such an attack
can facilitate serious data
loss or server takeover.
Applications using
components with known
vulnerabilities may
undermine application
defenses and enable a
range of possible attacks
and impacts.

OWASP > A10: Unvalidated Redirects and Forwards
Web applications frequently
redirect and forward users
to other pages and
websites, and use
untrusted data to determine
the destination pages.
Without proper validation,
attackers can redirect
victims to phishing or
malware sites, or use
forwards to access
unauthorized pages.

Understanding Encryption
• Allows Decryption
› Symmetric
- Shared Key
- Fast
› Asymmetric
- Requires a pair of keys
- Public and Private
- Slow
• No Decryption
› Hashing
- One-way
- Can’t get back original
- You can validate with original by hashing and comparing hashes
- SHA 256, MD5

Architecture of a .NET Website

Security Best Practices: IIS 8
•Installation and Configuration
•Web Application Isolation
•Authentication
•Request Filtering
•Application Pool Identities

Securing IIS: Installation & Configuration
• Don’t run IIS on a domain controller or a backup domain controller.
› Don’t even have IIS server join regular user domain
› Perhaps have a separate domain for your IIS servers.
• Install only the IIS modules you need.
› IIS 8 is composed of more than 40 modules
• Periodically remove unused or unwanted modules and handlers.
• For high volume installations of IIS, run other resource-intensive
products like SQL Server or Exchange on separate computers.
• Keep your antivirus software up to date.
• Move the Inetpub folder from your system drive to a different drive.
› Default is C drive.
› This helps in saving space on system drive.

Securing IIS: Application Pool Identities
• Don’t use the built-in service identities (e.g. Network Service, Local
Service, or Local System).
• The default (recommended) and most secure is
ApplicationPoolIdentity.
• Using a custom identity account is acceptable, but be sure to use a
different account for each application pool.
Reference: http://www.iis.net/learn/manage/configuring-security/application-pool-identities

Securing IIS: Web Application Isolation
• Isolate web applications.
› Separate different applications into different sites with different
application pools
• Implement the principle of least privilege.
› Run your worker process as a low privileged identity (virtual application
pool identity) that is unique per site.
• Isolate ASP.NET temp folders.
› Set up a separate ASP.NET temp folder per site and only give access
to appropriate process identity.
• Isolate content.
› Make sure to set an ACL (access control list) on each site root to allow
only access to the appropriate process identity.

Securing IIS: Request Filtering
• Ensure that request filtering rules are enabled.
• Rules
› File Name
› Rules
› Hidden Segments
› URL
› Http Verbs
› Headers
› Query Strings
Resource: https://technet.microsoft.com/en-
us/library/hh831621(v=ws.11).aspx

Securing IIS: Authentication
•Don’t allow anonymous writes to the server.
•Disable anonymous access to server directories
and resources
•Be aware that configuring Anonymous
authentication along with another authentication
type for the same website can cause
authentication problems.

Securing IIS: Miscellaneous
•Make periodic backups of the IIS server.
•Limit permissions granted to non-administrators.
•Turn on SSL and maintain SSL certificates.
•Use SSL when you use Basic authentication.
•No clear text password recovery
•Passwords should be hashed (SHA256)
› MD5 isn’t secure anymore

Website: Perform Regular Checkups
• Do a “view source” of your web application and look for iFrames,
malicious links and cookies
• Compare the filesystem between backups and look for new or
modified files
› You may find backdoor rootkit files in your website folder
- Tool: Beyond Compare
› Also compare database
- Tool: Redgate SQL Compare
• Review audit logs
› Look for unusual activities
• Review exception logs
› Look for unusual exceptions
• Look for new Users created in your system

How to Spot: Cross-Site Request Forgery
Cross-Site Request Forgery (CSRF) is a type of attack that occurs
when a malicious web site, email, blog, instant message, or
program causes a user’s web browser to perform an unwanted
action on a trusted site for which the user is currently
authenticated.
• Asp.Net ValidateAntiForgeryTokenAttribute
• Paired tokens (cookie and header)
› Must match
Source: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

How to Spot: Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) attacks are a type of
injection, in which malicious scripts are injected into
otherwise benign and trusted web sites.
XSS attacks occur when an attacker uses a web
application to send malicious code, generally in the
form of a browser side script, to a different end user.
Source: https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

Summary
• Website Security
• Security Questions to ask your Vendor
• OWASP: Concepts and Top 10
• Understanding Encryption
• High-Level Architecture of a .NET Website
• Regular Checkups
• How to spot CSRF
• How to spot XSS

Resources
› https://technet.microsoft.com/en-us/library/jj635855(v=ws.11).aspx
• Understanding CSRF, the video tutorial edition
› https://www.youtube.com/watch?v=hW2ONyxAySY
• Basic XSS Guide #1 - Alert() - Redirection - Cookie Stealing
› https://www.youtube.com/watch?v=486KmQOcwWg
• OWASP Top 10
› https://www.owasp.org/index.php/Top_10_2013-Table_of_Contents

For More Information About DNN
Visit our website for more information
about our secure, .NET CMS, Evoq:
http://www.dnnsoftware.com/products/evoq-content

How to Harden the Security of Your .NET Website

More Related Content

What's hot

Viewers also liked

Similar to How to Harden the Security of Your .NET Website

More from DNN

Recently uploaded

How to Harden the Security of Your .NET Website