Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How to Harden the Security of Your .NET Website


Published on

What keeps IT managers awake at night? Worrying whether their website is protected against security vulnerabilities and exploits.

In this presentation, Ash Prasad, Director of Engineering at DNN, gives IT managers suggestions on how to secure their .NET websites.

Ash shares the tools and techniques he employs to harden the security of websites. If you’re managing .NET websites, this presentation will arm you with tips you can apply right away.

Published in: Technology
  • With A6 it's also important to make sure you use a secure hashing algorithm. To quote the OWASP Top Ten website: 'Use strong hashes (SHA 256 or better) with salts for passwords.'. This is an important point since DNN doesn't support other hashing algorithms than SHA1 by default as far as I know.
    Are you sure you want to  Yes  No
    Your message goes here

How to Harden the Security of Your .NET Website

  1. 1. DNN / Proprietary and Confidential. All Rights Reserved.1
  2. 2. 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
  3. 3. 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
  4. 4. Website Security Website Security Infrastructure Security - Firewall, - Antivirus - OS Patching Application Security - XSS - CSRF - Injection
  5. 5. Security Questions to Ask Your Vendor • Do you issue Security Bulletins with your release? › For DNN Corp – Yes. • 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: • Do you have a tool to check security › For DNN Corp – Yes. blog/cid/155364/updates-to-security-analyzer-tool
  6. 6. 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:
  7. 7. 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
  8. 8. 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:
  9. 9. 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:
  10. 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.
  11. 11. 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.
  12. 12. 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.
  13. 13. 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.
  14. 14. 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.
  15. 15. 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.
  16. 16. 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.
  17. 17. 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.
  18. 18. 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.
  19. 19. 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
  20. 20. Architecture of a .NET Website
  21. 21. Security Best Practices: IIS 8 •Installation and Configuration •Web Application Isolation •Authentication •Request Filtering •Application Pool Identities
  22. 22. 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.
  23. 23. 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:
  24. 24. 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.
  25. 25. Securing IIS: Request Filtering • Ensure that request filtering rules are enabled. • Rules › File Name › Rules › Hidden Segments › URL › Http Verbs › Headers › Query Strings Resource: us/library/hh831621(v=ws.11).aspx
  26. 26. 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.
  27. 27. 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
  28. 28. 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
  29. 29. 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:
  30. 30. 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:
  31. 31. 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
  32. 32. Resources • Security Best Practices for IIS 8 › • Understanding CSRF, the video tutorial edition › • Basic XSS Guide #1 - Alert() - Redirection - Cookie Stealing › • OWASP Top 10 ›
  33. 33. For More Information About DNN Visit our website for more information about our secure, .NET CMS, Evoq: