DNN / Proprietary and Confidential. All Rights Reserved.1

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

• Security Best Practices for IIS 8

• Regular Checkups

• How to spot CSRF

• How to spot XSS

Resources

• Security Best Practices for IIS 8

› 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