Web application security (eng)
-
Upload
anatoliy-okhotnikov -
Category
Technology
-
view
310 -
download
4
description
Transcript of Web application security (eng)
Web Application Security21/03/2012
Softjourn Inc.
Web Application Security
Anatoliy Okhotnikov
Softjourn Inc.
Web Application Security
3/21/12
Agenda● Why this is important? What to do?
● Security threats & Mitigations
● Designing Secure Web Applications
● Building Secure Web Applications
● Securing Your Network, Web Server and Database
● Assessing Your Security
Why this is important?Web applications allow visitors
access to the most critical resources of a web site, the web server and the database server
Deface a web site Loss of trust with customers
and/or visitors Damaged brand reputation Lost sales revenue Your site labeled as a malicious Loss of search engine rankings
Why this is important? (more) Insert spam links directing visitors to another site Insert malicious code that installs itself onto a
visitor’s computer Insert malicious code that steals session IDs
(cookies) Steal visitor information and browsing habits Steal account information Steal information stored in the database Access restricted content And much more...
What to do?
reduces the likelihood of a successful attack and mitigates the extent of damage if an attack occurs. It resides on a secure host
(server) in a secure network and is developed using secure design and development
guidelines.
Build a hack-resilient application
Why this is important?
Security threats SQL injection OS Command injection Classic buffer overflow Cross-site scripting (XSS) Missing authentication
and/or authorization Direct site attacks more...
Security threats (more) Use of Hard-coded Credentials Missing Encryption of Sensitive Data Unrestricted Upload of File with Dangerous Type Reliance on Untrusted Inputs in a Security
Decision Execution with Unnecessary Privileges Cross-Site Request Forgery (CSRF) Improper Limitation of a Pathname to a
Restricted Directory ('Path Traversal') Download of Code Without Integrity Check even more...
Security threats (even more) Incorrect Authorization Inclusion of Functionality from Untrusted Control Sphere Incorrect Permission Assignment for Critical Resource Use of Potentially Dangerous Function Use of a Broken or Risky Cryptographic Algorithm Incorrect Calculation of Buffer Size Improper Restriction of Excessive Authentication
Attempts URL Redirection to Untrusted Site ('Open Redirect') Uncontrolled Format String Integer Overflow or Wraparound Use of a One-Way Hash without a Salt
Mitigations
Mitigations Establish and maintain control over all of
your inputs and outputs Lock down your environment Assume that external components can be
subverted, and your code can be read by anyone
Use industry-accepted security features instead of inventing your own
more...
Mitigations (more) Use libraries and frameworks that make it
easier to avoid introducing weaknesses Integrate security into the entire software
development lifecycle Use a broad mix of methods to
comprehensively find and prevent weaknesses
Allow locked-down clients to interact with your software
Designing Secure Web Applications
Designing Secure Web Applications Design input validation strategies Partition Web sites into open and restricted areas Implement effective account management practices Develop effective authentication and authorization
strategies Protect sensitive data Protect user sessions Prevent parameter manipulation Handle exceptions securely Secure an application’s configuration management
features List audit and logging considerations
Designing: input validation strategies
Designing: input validation strategies
Assume ALL input is malicious Centralize your approach Do not rely on client-side validation Be careful with canonicalization issues Constrain, reject and sanitize your
input Use common input handling practices
Designing: authentication
Designing: authentication
Separate public and restricted areas Use account lockout policies for end-user
accounts Support password expiration periods Be able to disable accounts Do not store passwords in user stores Require strong password Do not send password over the wire in
plaintext Protect authentication cookies
Designing: authorization
Use multiple gatekeepers Restrict user access to
system level resources Consider authorization
granularity
Designing: configuration management
Secure your administration interfaces
Secure your configuration stores
Separate administration privileges
Use least privileged process and service accounts
Designing: sensitive data
Secrets Sensitive per user data
Designing: session management
Use SSL to protect session authentication cookies
Encrypt the contents of the authentication cookies
Limit session lifetime Protect session state
from unauthorized access
Designing: cryptography
Do not develop your own cryptography
Keep unencrypted data close to the algorithm
Use the correct algorithm and correct key size
Secure your encryption keys
Designing: parameter manipulation
Encrypt sensitive cookie state
Make sure that users do not bypass your checks
Validate all values sent from the client
Do not trust HTTP header information
Designing: exception management
Do not leak information to the client
Log detailed error messages
Catch exceptions
Designing: auditing and logging
Audit and log access across application tiers
Consider identity flow
Log key events Secure log files Back up and
analyze log files regularly
Building Secure Web Applications
Building Secure Web Applications
Role-based Security, URL authorization
Code Access Security Be aware of unauthorized access,
privilege elevation, code injection, information disclosure, tampering
Log events Data Access Obfuscation
Secure Web App: class design
Restrict Class & Member Visibility
Seal Non-Base Classes
Restrict Which Users Can Call Your Code
Expose Fields Using Properties
Secure Web App: exceptions
Use Structured Exception Handling
Do Not Log Sensitive Data Do Not Reveal Sensitive
System or Application Information
Consider Exception Filter Issues
Consider an Exception Management Framework
Secure Web App: file I/O
Avoid Untrusted Input for File Names Do Not Trust Environment Variables Validate Input File Names Constrain File I/O Within Your
Applications' Context
Secure Web App: serialization
Do Not Serialize Sensitive Data Validate Serialized Data Streams Partial Trust Considerations
Secure Web App: threading
Do Not Cache the Results of Security Checks
Consider Impersonation Tokens Synchronize Static Class Constructors Synchronize Dispose Methods
Secure Web App: cryptography
Use Platform-provided Cryptographic Services
Key Generation Key Storage Key Exchange Key Maintenance
Secure Web App: architecture & design
Input validation Authentication Authorization Configuration Management Sensitive Data Session Management Cryptography Parameter Manipulation Exception Management Auditing & Logging
Securing Your Network, Web Server and Database
Securing your network Securing your web server Securing your database
Securing Your Network
Securing Your Network: routers Patch & Update Ingress & Egress Filtering / Screen Traffic Prevent TTL Expired Messages with Values of 1
or 0 Do Not Receive or Forward Directed Broadcast
Traffic Disable Unused Interfaces Apply Strong Password Policies Use Static Routing Audit Web Facing Administration Interfaces Auditing and Logging / Intrusion Detection
Securing Your Network: firewalls
Patch & Update Filters
Packet filters Circuit-level filters Application filters Stateful inspection Custom application filters
Logging & Auditing Perimeter Networks
Securing Your Network: switches
Patches & Updates Virtual Local Area Networks (VLANs) Insecure Defaults Services Encryption
Securing Your Web Server
Be aware of profiling, denial of service, unauthorized access, arbitrary code execution, elevation of privileges, viruses, worms and trojan horses
Patches & Updates. Services. Protocols. Accounts. Files & Directories. Shares. Ports. Auditing & Logging. Sites & Virtual Directories. Script Mappings. API Filters. Server Certificates. Permissions. Error Messages. Sample & test files.
Securing Your Database Be aware of SQL injection, network eavesdropping,
unauthorized server access, password cracking Patches & Upgrades. Disable unused server services Restrict server to TCP/IP, harden TCP/IP stack Secure DB accounts, delete or disable unused accounts,
enforce strong password policy, restrict remote logons, disable anonymous
Verify permissions on files & directories, secure or remove tools, utilities and SDKs
Restrict access to DB port Log all failed logon attempts, actions, enable SQL logging Run server using a least privileged account Do not grant permission to the public role Remove sample DBs, secure stored procedures
Assessing Your Security
Get organized. Establish the process
Standardize how you verify web application security (ASVS)
Assemble tools suite (OWASP Live CD Project)
Code review. CodeCrawler, Orizon, O2
Testing/Penetration. WebScarab
Assessment: Injection
Assessment: Injection Verify that all use of interpreters clearly
separates untrusted data from the command query.
Check the code. Code analysis tools can help. Penetration testing with exploits.
Automated dynamic scanning which exercises the application.
Assessment: Cross-Site Scripting (XSS)
Assessment: Cross-Site Scripting (XSS)
Ensure that all user supplied input sent back to the browser is verified to be safe and properly escaped before it is included in the output page.
Both static and dynamic tools can find some XSS problems automatically, but complete coverage requires a combination of manual code review and manual penetration testing.
Web 2.0 technologies, such as AJAX, make XSS much more difficult to detect via automated tools.
Assessment: Broken Authentication and Session Management
Assessment: Broken Authentication and Session Management
Are credentials always protected when stored using hashing or encryption?
Can credentials be guessed or overwritten through weak account management functions?
Are session IDs exposed in the URL? Are session IDs vulnerable to session fixation
attacks? Do sessions IDs timeout and can users log out? Are session IDs rotated after successful login? Are passwords, session IDs, and other credentials
sent over TLS connections?
Assessment: Insecure Direct Object References
Assessment: Insecure Direct Object References
Verify that all object references have appropriate defenses. Code review/testing.
For direct references to restricted resources, the application needs to verify the user is authorized to access the exact resource they have requested.
If the reference is an indirect reference, the mapping to the direct reference must be limited to values authorized for the current user.
Assessment: Cross-Site Request Forgery (CSRF)
Assessment: Cross-Site Request Forgery (CSRF)
Verify if each link and form contains an unpredictable token for each user.
Check multistep transactions, as they are not inherently immune.
Note that session cookies, source IP addresses, and other information that is automatically sent by the browser doesn't count since this information is also included in forged requests.
OWASP's CSRF Tester tool can help generate test cases to demonstrate the dangers of CSRF flaws.
Assessment: Security Misconfiguration
Assessment: Security Misconfiguration
Do you have a process for keeping all your software up to date? This includes the OS, Web/App Server, DBMS, applications and all code libraries.
Is everything unnecessary disabled, removed or not installed (eg ports, services, pages, accounts, privileges)?
Are default account passwords changed or disabled? Is your error handling set up to prevent stack traces
and other overly informative error messages from leaking?
Are the security settings in your development frameworks and libraries understood and configured properly?
Assessment: Insecure Cryptographic Storage
Assessment: Insecure Cryptographic Storage
Which data is sensitive enough to require encryption?
Is it encrypted everywhere it is stored long term, particularly in backups of this data?
Can the authorized users only access decrypted copies of the data?
Is a strong standard encryption algorithm used?
Is a strong key generated, protected from unauthorized access and key change is planned for?
Assessment: Failure to Restrict URL Access
Assessment: Failure to Restrict URL Access
Verify every page. Consider is the page supposed to be public or private. Is authentication required to access a private page? Is a private page supposed to be accessible to ANY
authenticated user? If not, is an authorization check made to ensure the user has permission to access that page?
Verify external security mechanisms are properly configured for every page? If code level protection is used, verify that it is in place for every required page.
Penetration testing can also verify whether proper protection is in place.
Assessment: Insufficient Transport Layer Protection
Assessment: Insufficient Transport Layer Protection
Is SSL used to protect all authentication related traffic?
Is SSL used for all resources on all private pages and services?
Are strong algorithms only supported? Have all session cookies their 'secure' flag
set? Is the server certificate legitimate and
properly configured for that server?
Assessment: Unvalidated Redirects and Forwards
Assessment: Unvalidated Redirects and Forwards
Review the code for all uses of redirect or forward. For each use, identify if the target URL is included in any parameter values. If so, verify the parameter(s) are validated to contain only an allowed destination, or element of a destination.
Spider the site to see if it generates any redirects (300-307). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such URL. If so, change the URL target and observe whether the site redirects to the new target.
If code is unavailable, check all parameters to see if they look like part of a redirect or forward URL destination and those that do.
Assessment: Additional Risks to Consider
Assessment: Additional Risks to Consider
Clickjacking (UI redress attack) Concurrency flaws Denial of service Header injection Information leakage and Improper error
handling Insufficient anti-automation Insufficient logging and accountability Lack of intrusion detection and response Malicious file execution
Copyright © 2000-2011 Softjourn, Inc. All rights reserved
Links• http://en.wikipedia.org/wiki/Web_application_s
ecurity• http://cwe.mitre.org/top25/• http://msdn.microsoft.com/en-
us/library/ff649874.aspx• http://www.applicure.com/solutions/web-
application-security• http://www.clusif.asso.fr/fr/production/ouvrage
s/pdf/CLUSIF-2010-Web-application-security.pdf
• http://www.webappsec.org/• http://code.google.com/p/owasptop10/
Copyright © 2000-2011 Softjourn, Inc. All rights reserved
Questions & discussion“Anatoliy Okhotnikov”