Outline. 1 Introduction. 2 Security Architecture and Design. 3 Threat Risk Modelling. 4 Phishing. 5 Web Services. 6 Secure Coding Guidelines

Size: px

Start display at page:

Download "Outline. 1 Introduction. 2 Security Architecture and Design. 3 Threat Risk Modelling. 4 Phishing. 5 Web Services. 6 Secure Coding Guidelines"

Blaze Rice
6 years ago
Views:

1 Web Security Prakash Chandrasekaran Microsoft Research India prakash on leave from Chennai Mathematical Institute ISEA, IMSc, 25 & 26 May 2006 Overview Web Applications MVC This presentation is licensed under the Free Documentation License. Permission is granted to copy, distribute, and/or modify this document provided this copyright notice and the acknowledgement and reference slides are retained. Copyright c 2006, Prakash Chandrasekaran. All Rights Reserved. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Introduction In this talk we will look at various aspects of security involved in web communication: What are Web Applications Secure Architecture and Design Threat Risk Modelling Secure Coding Guidelines PHP Guidelines Web Applications In the early days of the web, web sites consisted of static pages. Then came CGI that allowed execution of external programs. But CGI is not very useful has lots of disadvantages more overhead due to process creation, lack of session management, lack of authorization controls. Scripting - The interpreters run script code within the web server process. Scripting languages too have some disadvantages They are in general not very strongly typed They are very slow compared to native code in CGI Its difficult to write multi-tier large scale applications Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

2 Web Applications Small to Medium Scale Applications Most applications fall into this category. The usual architecture is a simple liner procedural script. Its easy to develop, and not much skill is required to maintain the codebase. typically has lots of security issues, mostly due to insufficiently validated input data. Large Scale Applications Larger applications need a different architecture than that of a simple feedback form. Scalable application architecture is often divided into different tiers, and modules. One of the most common web application architecture is model-view-controller (MVC). MVC MVC implements the Smalltalk 80 application architecture. MVC is typical of most Apache Foundation Jakarta Struts J2EE applications. Code behind ASP.NET can be considered a partial implementation of this approach. For PHP, the WACT project aims to implement the MVC paradigm. MVC - View - The font rendering code often called the presentation tier. Controller - Takes input from the users and gates it through various workflows. Model - Encapsulates functionality, and is transparent to the caller and provides a method to deal with high-level business processes. A good model will allow pseudo code like oaccount TransferFunds(fromAcct,toAcct,amount) rather than a long piece of code that checks for funs availability, withdraws the amount from fromacct, then deposits in toacct. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Policy Frameworks Secure Coding Principles Policy Framework Secure applications so not just happen - they are the result of organizational policy decision. To develop a secure application, a well written security policy is very important. The development cycle should have adequate security checkpoints. Ad-Hoc development is not structured enough to produce secure applications. Coding standards are also very important. Methodologies are not coding standards. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

3 Secure Coding Principles Classify assets. Consider potential attackers. Put yourself in the shoes of the attackers. Minimize attack surface area. Have secure default values. Principle of least privilege. Principle of Defense in Depth - tier based validation Fail Securely External systems are insecure Separation of Duties Do not trust Security through Obscurity Simplicity Fix security issues correctly. Introduction Using Microsoft TM Process Steps in Threat Modelling Application Overview Types of Attacks Damage Potential Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Threat Risk Modelling When designing your application, it is essential you design using threat risk assessed controls, otherwise you will squander resources, time and money on useless controls and not enough on the real risks. The method you use to determine risk is not nearly as important as actually performing structured threat risk modeling. TRM using MS TM Process Microsoft provides a threat modeling tool written in.net to assist with tracking and displaying threat trees. There are five steps in the threat modeling process. Identifying Security Objectives Application Overview Identify Vulnerabilities Decompose Application Identify Threats Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

4 TRM using MS TM Process Identifying Security Objectives Identity: does this application protect user 2019s identity from misuse? Reputation: the loss of reputation derived from the application being misused or successfully attacked Financial: the level of risk the organization is prepared to stake in remediation potential financial loss. Privacy and regulatory: to what extent shall applications protect user s data. Availability guarantees: Highly available applications and techniques are extraordinarily expensive, so setting the correct controls here can save a great deal of time, resources, and money. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Application Overview Once the security objectives have been defined, the application should be analyzed to determine: Components Data Flow Trust Boundaries Look for UML component diagrams, to understand data flow. Once the application is understood, it needs to be decomposed. For example, when investigating the authentication module, it is necessary to understand how data enters the authentication module, how the module validates and processes the data, where the data flows, if data is stored, and what decisions are made by the module. Application Overview Document known threats A threat graph A structured list of threats To understand what threats are applicable, use the security objectives to understand who might attack the application: Accidental discovery: authorized users stumble across a mistake in your application logic using just a browser. Curious Attacker (such as security researchers or users who notice something wrong with your application and test further) Script kiddie: computer criminals attacking or defacing applications for respect or political motive Motivated attacker (such as disgruntled staff or paid attacker) Organized crime (generally for higher risk applications, such as e-commerce or banking) Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

5 Types of Attacks Spoofing Identity Tampering with data Repudiation Information Disclosure Denial of Service Elevation of privilege Damage Potential Reproducibility Exploitability Affected Users Discoverability Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 What is Phishing? Phishing Phishing is misrepresentation where the criminal uses social engineering to appear as a trusted identity. They leverage the trust to gain valuable information; usually details of accounts, or enough information to open accounts, obtain loans, or buy goods through e-commerce sites. What is phishing Basic Phishing Attack What you can do about Phishing? Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

6 Basic Phishing Attack Delivery via a website, , or instant message. Sending threatening s Through installed Spyware. Spurious Security Alerts. What you can do about Phishing? Educate your users Consistent branding Reduce risk - ex: do not send with active content. Increase Trust - consider using digital signatures Incident response - don t send users about fraud, instead lock their accounts and given them a contact number, or better ring them! Don t use pop-ups or frames. Check the client environments, including the DOM. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Securing Web Services Communication Security Using Tokens Securing Web Services Web Service, like other distributed applications, require protection at multiple levels: SOAP messages that are sent on the wire should be delivered confidentially and without tampering The server needs to be confident who it is talking to and what the clients are entitled to The clients need to know that they are talking to the right server, and not a phishing site System message logs should contain sufficient information to reliably reconstruct the chain of events and track those back to the authenticated callers Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

7 Communication Security There is a commonly cited statement, and even more often implemented approach - we are using SSL to protect all communication, we are secure. It provides only point-to-point security There is also a subtle issue of trust transitivity, as trusts between node pairs A,B and B,C do not automatically imply A,C trust relationship. Storage issue After messages are received on the server (even if it is not the intended recipient), they exist in the clear-text form, at least - temporarily. Communication Security... Lack of interoperability While SSL provides a standard mechanism for transport protection, applications then have to utilize highly proprietary mechanisms for transmitting credentials, ensuring freshness, integrity, and confidentiality of data sent over the secure channel. Passing Credentials Since SOAP messages are XML-based, all passed credentials have to be converted to text format. Passing credentials carries an inherited risk of their disclosure - either by sniffing them during the wire transmission, or by analyzing the server logs. Ensuring message freshness Protecting message integrity, and confidentiality. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Communication Security... Access Control do we know who is requesting the operation (Identification) can we verify the caller s identity claim (Authentication) is the caller allowed to perform this operation (Authorization) Using Tokens Types of tokens in SOAP messages: Username token - Defines mechanisms to pass username and, optionally, a password - the latter is described in the username profile document. Unless whole token is encrypted, a message which includes a clear-text password should always be transmitted via a secured channel. Binary token - They are used to convey binary data, such as X.509 certificates, in a text-encoded format, Base64 by default. XML token - These are meant for any kind of XML-based tokens. Tokens are only a mechanism, and by themselves do not provide any security. Use time-stamps along with tokens to ensure freshness. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

8 Authentication Basic authentication - sends password in clear text Digest authentication - obfuscates password in HTTP1.0, and uses challenge response in HTTP1.1 Form based authentication - vulnerable to replay attack, man in the middle attack, Phishing, etc. Integrated authentication - used for intranet purposes Certificate based authentication Strong authentication - tokens, certificates etc. Authentication Session Management Data Validation Interpreter Injection Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Authentication Use principle of least privilege Use ACLs and Access Control Matrix to determine access privilege at each non-anonymous entry point. Use Centralized authorization routines, and not re-write / copy-paste code every time. Do not store session information on client side (in cookies). Session Management Authorization and role data should be stored only on the server. Navigation data in URLs is acceptable as long as they can be validated. Avoid permissive session generation - ie. simply issue a new session ID, if one does not exist. Secure session data stored on the server. Use page specific nonces in conjunction with session tokens. Tokens should be sent only on encrypted channels (eg. SSL, TSL). Use session timeouts. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

9 Session Authorization Attacks One of the most common mistakes is not checking authorization prior to performing a restricted function or accessing data. Just because a user has a session does not authorize them to use all of the application or view any data. A particularly embarrassing real life example is the Australian Taxation Office s GST web site, where most Australian companies electronically submit their quarterly tax returns. The ATO uses client-side certificates as authentication. Sounds secure, right? However, this particular web site initially had the ABN (a unique number, sort of like a social security number for companies) in the URL. These numbers are not secret and they are not random. A user worked this out, and tried another company s ABN. To his surprise, it worked, and he was able to view the other company s details. He then wrote a script to mine the database and mail each company s nominated address, notifying each company that the ATO had a serious security flaw. More than 17,000 organizations received s. Data Validation Data validation is a very critical part in securing web applications. Insufficiently validated code, used in sensitive operations like SQL queries, can be fatal. Hidden form-fields are one way of saving state on the client side, instead of on the server. But they should be validated before use, as they can still be altered by a malicious user/program. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Interpreter Injection User Agent Injection - the browser could be compromised. DOM based XSS Injection - allows attacker to introduce hostile code into vulnerable client-side Javascript embedded in many pages. SQL, ORM, LDAP, XML Injections All of the above can be safeguarded against by always validating input data, before using it any form. Global Variables Include and Remote Files Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

10 PHP Guidelines PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely used server-side scripting language for creating dynamic web pages. Server-side means that the code is interpreted on the server before the result is sent to the client. PHP code is embedded in HTML code and it is easy to get started with, while still very powerful for the experienced programmer. However being extremely feature rich and easy to get started with is not only positive, it to often leads to insecure applications vulnerable to several different kinds of attacks. Global variables Variables declared outside of a function are considered global by PHP. Unlike C, in PHP, to use a global variable from local scope you have to declare it global in that scope. register globals make input from GET, POST, and COOKIE, as well as session variables etc. directly accessible as global variables in PHP. This directive, if set in php.ini, is the root of many vulnerabilities. Whenever needed always use superglobal arrays like $ GET, $ POST, $ SESSION. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Include and Remote Files The include and require directives provide means to import code into the current script. If the file name is a HTTP URL, then PHP will fetch it and import it. Consider the following example: //file.php $sincpath= /inc/ ; include($sincpath. functions.php );... //functions.php include($sincpath. filesystem.php ); In above functions.php assumes that $sincpath has been set to a proper value. If register globals is set, the an attacker can directly invoke functions.php with a $sincpath that says something like and the server will now include that script and execute it. Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

11 For Further Reading A Guide to Building Secure Web Applications and Web Services The Open Web Application Security Project This presentation is also available at prakash/isea2006 Prakash Chandrasekaran (MSRI,CMI) Web Security ISEA, IMSc, May / 41

Copyright

Copyright 1 Security Test EXTRA Workshop : ANSWER THESE QUESTIONS 1. What do you consider to be the biggest security issues with mobile phones? 2. How seriously are consumers and companies taking these threats?