Transcript Threats and Threat Modeling

Изграждане на сигурни уеб
приложения - заплахи и
методи на защита
Иво Моравски
MCT, MCSD.NET
CTEC-BG
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 (DoS)
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
Arbitrary code
execution
File disclosure
Denial of service (DoS)
Unauthorized access
Exploitation of open
ports and protocols
Examples
Buffer overflows in ISAPI DLLs (e.g., MS01-033)
Directory traversal attacks (MS00-078)
Malformed HTR requests (MS01-031)
Virtualized UNC share vulnerability (MS00-019)
Malformed SMTP requests (MS02-012)
Malformed WebDAV requests (MS01-016)
Malformed URLs (MS01-012)
Brute-force file uploads
Resources with insufficiently restrictive ACLs
Spoofing with stolen login credentials
Using NetBIOS 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
Medium
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
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-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
HttpUtility.HtmlEncode
Request.MapPath
ASP.NET 1.1 request
validation
Description
Class in System.Text.RegularExpressions
namespace that wraps .NET Framework's regular
expression engine
Set of six controls that validate input on both
client and server: RequiredFieldValidator,
RegularExpression-Validator, RangeValidator, 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);
SqlCommand command = new SqlCommand (sql, connection);
int count = (int) command.ExecuteScalar ();
Stored Procedures
Less vulnerable to SQL injection attacks
Added security via EXECUTE permission
// BEST: Input passed to stored proc
SqlCommand command =
new SqlCommand ("proc_IsUserValid", connection);
command.CommandType = CommandType.StoredProcedure;
command.Parameters.Add ("@username",
SqlDbType.VarChar).Value = username;
command.Parameters.Add ("@password",
SqlDbType.VarChar).Value = password;
command.Parameters.Add ("@return", SqlDbType.Int).
Direction = ParameterDirection.ReturnValue;
int count = (int) command.ExecuteScalar ();
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
Company policies
sometimes require userlevel auditing of database
accesses
Increased granularity of
database permissions
Connection pooling
No one-hop issues
Cons
ASPNET account lacks
network credentials
All callers share one set of
database permissions
Foils connection pooling
Raises one-hop issues
Added administration
Grants database access to
more principals
Decreased performance
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
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
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 loginUrl="https://.../LoginPage.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 <customErrors> 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.