Upload
dnn
View
1.101
Download
1
Embed Size (px)
Citation preview
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: [email protected]
• 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