Session Agenda Threats Types of threats Threats against

Session Agenda - Threats Types of threats Threats against the application SQL injection Cross-site scripting Input tampering Session hijacking More Threat modeling

Session Agenda - Countermeasures Holistic approach to security Writing secure code Validating input Accessing databases securely Using forms authentication securely Storing secrets securely Securing session state Handling errors properly

Types of Threats Network Host Threats against the network Spoofed packets, etc. Threats against the host Buffer overflows, illicit paths, etc. Threats against the application SQL injection, XSS, input tampering, etc. Application

Threats Against the Network Threat Information gathering Examples Eavesdropping Denial of service (Do. S) Port scanning Using trace routing to detect network topologies Using broadcast requests to enumerate subnet hosts Using packet sniffers to steal passwords SYN floods Spoofing ICMP echo request floods Malformed packets Packets with spoofed source addresses

Threats Against the Host Threat Examples Arbitrary code execution Buffer overflows in ISAPI DLLs (e. g. , MS 01 -033) Directory traversal attacks (MS 00 -078) File disclosure Malformed HTR requests (MS 01 -031) Virtualized UNC share vulnerability (MS 00 -019) Denial of service (Do. S) Unauthorized access Exploitation of open ports and protocols Malformed SMTP requests (MS 02 -012) Malformed Web. DAV requests (MS 01 -016) Malformed URLs (MS 01 -012) Brute-force file uploads Resources with insufficiently restrictive ACLs Spoofing with stolen login credentials Using Net. BIOS and SMB to enumerate hosts Connecting remotely to SQL Server

Threats Against the Application Threat SQL injection Cross-site scripting Hidden-field tampering Eavesdropping Session hijacking Identity spoofing Information disclosure Examples Including a DROP TABLE command in text typed into an input field Using malicious client-side script to steal cookies Maliciously changing the value of a hidden field Using a packet sniffer to steal passwords and cookies from traffic on unencrypted connections Using a stolen session ID cookie to access someone else's session state Using a stolen forms authentication cookie to pose as another user Allowing client to see a stack trace when an unhandled exception occurs

SQL Injection

Cross-Site Scripting

Session Hijacking Web applications use sessions to store state Sessions are private to individual users Sessions can be compromised Threat Risk Factor Theft and replay of session ID cookies Links to sites that use cookieless session state Predictable session IDs Remote connection to state server service Remote connection to state server database Eavesdropping on state server connection High* Medium* Low* Medium * Shorter session time-outs mitigate the risk by reducing the attack window

Identity Spoofing Security depends on authentication If authentication can be compromised, security goes out the window Authentication can be compromised Threat Theft of Windows authentication credentials Theft of forms authentication credentials Theft and replay of authentication cookies Dictionary attacks and password guessing * Depends on the time-out values assigned to authentication cookies Risk Factor High Medium* High

Information Disclosure Which is the better error message?

Threat Modeling Structured approach to identifying, quantifying, and addressing threats Essential part of development process Just like specing and designing Just like coding and testing

The Threat Modeling Process 1 Identify assets 2 Document architecture 3 Decompose application 4 Identify threats 5 Document threats 6 Rate threats

Example – Identifying Assets Asset #1 Asset #2 Database Server Web Server Bob Bill Login Firewall Alice Asset #3 IIS ASP. NET Main State Asset #4 Asset #5 Asset #6

Example – Decomposing App Forms Authentication URL Authorization Web Server Trust Database Server Bob Bill Login Firewall Alice IIS ASP. NET Main State DPAPI Windows Authentication

Identifying Threats: STRIDE model S Spoofing Can an attacker gain access using a false identity? T Tampering Can an attacker modify data as it flows through the application? R Repudiation If an attacker denies an exploit, can you prove him or her wrong? I Information disclosure Can an attacker gain access to private or potentially injurious data? of service D Denial Can an attacker crash or reduce the availiability of the system? of privilege E Elevation Can an attacker assume the identity of a privileged user?

Rating Threats Simple model Risk = Probability * Damage Potential 1 -10 Scale 1 = Least probable 10 = Most probable 1 = Least damage 10 = Most damage Other models

Defenses and Countermeasures

Session Agenda - Countermeasures Holistic approach to security Writing secure code Validating input Accessing databases securely Storing secrets securely Using forms authentication securely Securing session state Handling errors properly

Holistic Approach to Security Network Defend the network Port blocking Filtering Encryption Spoofed packets, etc. Host Updates IIS hardening ACLs CAS Logging Least privilege Account mgmt. Defend the host Buffer overflows, illicit paths, etc. Defend the application SQL injection, XSS, input tampering, etc. Application Validation Hashing Encryption Secrets mgmt. Cookie mgmt. Session mgmt. Error handling

Defending the Network Harden firewalls • Stay current with patches and updates • Block unused ports and protocols • Use filtering to reject illicit requests Harden routers and switches • Stay current with patches and updates • Use ingress/egress filtering to reject spoofed packets • Screen ICMP traffic from the internal network • Screen directed broadcast requests from the internal network • Reject trace routing requests Encrypt sensitive communications

Defending the Host Stay current with service packs and updates Harden IIS with IISLockdown and URLScan Harden the Web server's TCP/IP stack Run ASP. NET using principle of least privilege ACL resources to prevent unauthorized access Disable unused shares and services Move Web root to drive other than C:

Defending the Application Never trust user input (validate!) Access databases securely Avoid vulnerabilities in forms authentication Secure ASP. NET session state Store secrets securely Anticipate errors and handle them appropriately

Validating Input Filter potentially injurious characters and strings HTML-encode all input echoed to a Web page Avoid using file names as input if possible

Tools for Validating Input Tool Regex Validation controls Http. Utility. Html. Encode Request. Map. Path ASP. NET 1. 1 request validation Description Class in System. Text. Regular. Expressions namespace that wraps. NET Framework's regular expression engine Set of six controls that validate input on both client and server: Required. Field. Validator, Regular. Expression-Validator, Range. Validator, etc. HTML-encodes input, converting potentially dangerous characters such as "<" into harmless escape sequences Resolves path names and optionally checks for path names that violate application boundaries Feature of ASP. NET 1. 1 that automatically rejects requests containing certain characters and character sequences (e. g. , "<script")

Input Validation

Accessing Data Securely Use stored procedures or parameterized commands in lieu of dynamic SQL commands Never use sa to access Web databases Store connection strings securely Apply administrative protections to SQL Server Optionally use SSL/TLS or IPSec to secure the connection to the database server

Dynamic SQL Commands Vulnerable to SQL injection attacks // DANGER! User input used to generate database query string sql = String. Format ("select count (*) " + "from users where username='{0}' and cast " + "(password as varbinary)=cast ('{1}' as " + varbinary)", username, password); Sql. Command command = new Sql. Command (sql, connection); int count = (int) command. Execute. Scalar ();

Stored Procedures Less vulnerable to SQL injection attacks Added security via EXECUTE permission // BEST: Input passed to stored proc Sql. Command command = new Sql. Command ("proc_Is. User. Valid", connection); command. Command. Type = Command. Type. Stored. Procedure; command. Parameters. Add ("@username", Sql. Db. Type. Var. Char). Value = username; command. Parameters. Add ("@password", Sql. Db. Type. Var. Char). Value = password; command. Parameters. Add ("@return", Sql. Db. Type. Int). Direction = Parameter. Direction. Return. Value; int count = (int) command. Execute. Scalar ();

The sa Account For administration only; never use it to access a database programmatically Instead, use one or more accounts that have limited database permissions For queries, use SELECT-only account Better yet, use stored procs and grant account EXECUTE permission for the stored procs Reduces an attacker's ability to execute harmful commands (e. g. , DROP TABLE)

Windows Authentication Microsoft SQL Server supports two types of authentication: Authentication using SQL Server logins Authentication using Windows identities Windows authentication reduces threat surface area by eliminating user names and passwords from connection strings server=localhost; database=pubs; Trusted_Connection=yes

Whom Do You Authenticate? Identity Worker process Impersonated identity COM+ identity Pros ¢ Connection pooling ¢ No one-hop issues Cons ¢ ASPNET account lacks network credentials ¢ All callers share one set of database permissions ¢ Company policies ¢ Foils connection pooling sometimes require user¢ Raises one-hop issues level auditing of database ¢ Added administration accesses ¢Increased granularity of ¢ Grants database access to more principals database permissions ¢ Connection pooling ¢ Decreased performance ¢ No one-hop issues ¢ Increased complexity ¢ All callers share one set of database permissions

Storing Secrets - Connection Strings Storing plaintext database connection strings in Web. config is risky Vulnerable to file disclosure attacks Storing encrypted database connection strings increases security Encrypting connection strings is easy System. Security. Cryptography classes Key management is not Where do you store the decryption key? See “How to Create a DPAPI Library” for instructions on creating your own library

Data Protection API (DPAPI) Present in Windows 2000 and higher Provides strong encryption, automatic key generation, and secure key storage Triple-DES encryption PKCS #5 key generation Two “stores”: User store – Per-user keys based on profiles Machine store – Per-machine keys with optional entropy values

Securing Connection Strings Description ¢ Store encrypted connection strings in Web. config ¢ Store key in ACLed registry entry ¢ Store encrypted connection strings in Web. config ¢ Let DPAPI perform key management ¢ Store encrypted connection strings in ACLed registry key ¢ Let DPAPI perform key management ¢ Use entropy values to harden DPAPI encryption ¢ Store entropy values in ACLed registry key Security Good Better Best

Forms Authentication Protect login credentials with SSL/TLS Don't store passwords; store password hashes Limit authentication cookie lifetimes to minimize windows for replay attacks Assume authentication cookies are spoofed or stolen when performing sensitive operations Don't rely on forms authentication to protect resources not owned by ASP. NET

Protecting Login Credentials Place login forms in directories protected by SSL/TLS to guard against eavesdropping <authentication mode="Forms"> <forms login. Url="https: //. . . /Login. Page. aspx" /> </authentication> Encrypted connection

Storing Login Passwords Don't store passwords in login databases Store password hashes for added security Salt hashes to impede dictionary attacks Format Plaintext passwords Encrypted passwords 1 -way password hashes Salted password hashes Comments Exposes entire application if database is compromised Better than plaintext, but still vulnerable if decryption key is compromised Better than encrypted passwords, but still vulnerable to dictionary attacks Less vulnerable to dictionary attacks

Authentication Cookies Forms authentication cookies are encrypted and validated by default Prevents reading and alteration Doesn’t prevent theft and replay Preventative measures are required to defend against unauthorized access Defense Comments Restrict cookies to SSL Prevents cookie theft (strongest defense) Limit cookie lifetime Mitigates replay attacks by limiting attack window Disable sliding renewal Mitigates replay attacks by limiting attack window

ASP. NET View State Great alternative to hidden fields when round-tripping data to the client Validated by default Encrypted if desired

Securing Session State Limit session time-outs as much as possible Avoid using cookieless session state if possible Close port 42424 in firewall if using state service Disable ASP. NET state service if you're not using it Close ports 1433 and 1434 if using SQL Server Encrypt connection string if using SQL Server

Session State, Cont. Don’t store potentially injurious data (such as credit card numbers) in session state Optionally use SSL/TLS to protect session ID cookies Optionally use SSL/TLS or IPSec to secure the connection to the database server

Error Handling Anticipate errors and handle them sensibly Use <custom. Errors> to display custom error pages Don't reveal too much information in error pages Beware mode="off" and debug="true" Log unhandled exceptions Be aggressive about logging failures

© 2003 -2004 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.