Common Threats and Effective Resolutions For Web Applications

Transcription

1 Common Threats and Effective Resolutions For Web Applications WHITE PAPER Threats Resolutions

2 Abstract In any computer application, the security of the application is the main concern for any developer. Security is provided not only at the code level but also for the final hosted product. An application hosted on a cloud requires additional security as a hacker can use security loopholes to hack most web-applications with significant ease. A developer has to focus on providing application security for a product throughout the lifecycle of its code in order to prevent any gaps in the security policy of this particular product or the underlying system owing to flaws in design, development, deployment an upgrade, maintenance and the database of the product. The majority of attacks on web application occur due to cross-site scripting (XSS) and SQL injection attacks, which occur owing to flawed coding and a failure to sanitize input and output from the web application. Thirty seven percent of the hit ratio is caused by these types of attacks while other vulnerabilities such as denial-of-service attacks, session hijacking, parameter manipulation, buffer- overflow and arbitrary code execution. This white paper lists some of the main security practices in the software development process, primarily for webapps, and explains how the developer can prevent a security attack on any application. The security of a web application should be enhanced by applying security checkpoints and techniques not only in the early stages of development but also throughout the software development life cycle. Special attention should be applied to the design and coding phase of development. A few of the security mechanisms that are frequently used include threat modeling, risk analysis, static code analysis and digital signature. A few of the security mechanisms that are frequently used include threat modeling, risk analysis, static code analysis and digital signature. Contents 1) A prototype of Web application architecture 2) Types of high level threats, classified according to components 3) A programmer's perspective of 10 common threats to OWASP (specific threats) 4) Security Software Development Cycle a. Identifying security requirements b. Threat modeling c. Secure design and coding guidelines d. Ensuring security on 3P components e. Testing for security f. Secure deployment - IT security g. Releasing Security patches 5) Popular Tools for Threat Modeling 6) Security review using Static Code Review 7) Security review using Runtime Penetration Testing 8) Celstream's expertise 2

3 1. A prototype of Web Application Architecture Users External Systems Service Consumers Presentation Layer UI Components UI Process Components Service Layer Business Layer Service Interfaces Business Workflows Application Facade Business Components Message Types Business Entities Cross-Cutting Security Operational Management Communication Data Layer Data Access Components Data Helpers / Utilities Service Agents Data Sources Services In the diagram displayed above, application security is depicted as a layer running through and touching all OSI layers. 2. Types of High level threats (classified according to components) The matrix displayed below depicts not only how each type of threat affects each web component but also the web application layer in which the attack occurs. In the table displayed above, a 'Yes' in a cell indicates that a particular threat can affect that component. Additionally, a threat can indirectly affect other layers located downstream. For example, the presentation layer is upstream when compared to the deployment layer. While the configuration layer includes aspects of the network layer, the deployment layer encompasses the environment layer. 3

4 The table displayed below depicts general vulnerabilities and the tools that can detect them. 4

5 3. A programmer's view of 10 common threats to OWASP (specific threats) The top ten vulnerabilities of OWASP are listed below. a) Injection b) Cross-Site Scripting (XSS) c) Broken Authentication and Session Management d) Insecure Direct Object References e) Cross-Site Request Forgery f) Security Misconfiguration g) Insecure Cryptographic Storage h) Failure to Restrict URL Access I) Insufficient Transport Layer Protection j) Non-validated Redirects and Forwards In the next section, a brief description of each type of vulnerability is provided. a. Injection Injection involves the introduction / injection of an alien code at the server side and the subsequent execution of that alien code. Injection can be done in a web application or website that is not well validated through vulnerable entry points, generally through a user interface component where the user enters text directly. The vulnerability of input data is directly related not only to basic input validations but also to 'white list' and 'black list' specific entries. We will see what 'white and black lists' are later in this article, when we discuss the resolutions for an injection attack. There are many types of injection, from SQL to system level shell commands. Common injections include SQL, XPath, XQuery, LDAP and Shell command. When a user input is accepted and executed on the server side in a web application, implementation uses inputs to fill in slots in order to make a final executable command (the command could be any one of the types mentioned above like SQL, ldap etc.). For example, if we are developing a search feature, we tend to accept the search string / criteria from the user and use it to develop an SQL query at the server end and execute it on the database. The results are displayed after these stages. If the input to this search criteria is not validated for vulnerabilities, an attacker can write a criteria string, using trial and error, which can have a correct SQL where clause. The next step involves composing this clause into the server side query where it forms a syntactically correct SQL query, which is gets executed and the results are returned to UI interface. A similar attempt on an LDAP based search provides information about each and every user in an organization. After having described an 'SQL INJECTION' briefly, we take a look at the variety of methods to handle this type of attack. Preventing these vulnerabilities from occurring is a better strategy than providing a solution after the vulnerability has occurred. Before we proceed further, let us see how a 'blacklist' differs from a 'white list'. In the situation mentioned above, the word 'List' means 'a collection of items'. As we had discussed earlier, an SQL injection involves text that can form a valid executing command at the server end. The first step requires checking whether this 'text' is anything similar to our requirements in our current business. For instance, consider an example where we are accepting input from a user enquiring about the train schedule. It is necessary to verify if these values are relevant to train schedules. In this case, a specific group of nouns and proper nouns are considered relevant. 5

6 We ensure the safety of input by ensuring that the user enters values found on a list prepared specifically for this purpose. On the other hand, if the user enters values that are not on the list, we can validate this data either on the UI front before it reaches the backend server or at the server end. As a result, we can avoid any damage of our website / web app. In a 'black' list, it is verified if the user input is available on a known list of values that are related to SQL command key words like SELECT, INSERT and WHERE. The list is called a 'blacklist' because the items on this list are not allowed or might be treated as an intrusion attempt. This type of validation is minimalistic in nature and effective in controlling this type of attack in most cases. Another method of protecting the application from these types of attacks involves designing the server side code in such a way that user input is not treated as a filler in the final command but as an input / parameter value. We achieve this task by implementing a parameterized query instead of a simple query. In a parameterized query, the input is passed to the final query as a value of one of the columns in the 'where' clause. As a result, even though an attacker might try to bypass the basic listing, we can still block the attack. b. Cross-Site Scripting (XSS) While dealing with web applications, we come across issues tagged with the key word 'XSS'. General surveys conducted by web security agencies conclude that approximately 80% of total threats reported worldwide are related to XSS. The havoc created by this type of attack ranges from simple pranks to real security breaches. As we have obtained a basic understanding about XSS, we can now learn about how destructive it is. XSS stands for Cross-site Scripting. The phrase 'crosssite' indicates that there are more than one web site involved in this type of attack and 'scripting' is a piece of code that can run on a browser, generally in a web development context. of code that can run on a browser, generally in a web development context. After this explanation, we will perceive that this type of attack has something to do with an executable code, which is not from a genuine source, trying to execute on a victim's machine. In the next paragraph, we will take a deeper look at how XSS functions. In a typical XSS attack, there are three elements involved. The attacker or the beneficiary, the victim, and a genuine web site (a compromised content source). First, the source web site is compromised by the attacker (we will see how this is done later in this article). When the victim tries to access webpages from this website, he/she receives malicious script mixed with actual content. When this malicious script enters a client's machine, the browser executes this script. The script executed by a browser has access to all types of sensitive data that are part of a secure transaction that takes place between client and server. Important information like session related information and user credentials can be redirected by the malicious code to the attacker's own destination. There are three types of XSS attacks namely stored, reflected and DOM based. XSS I picked is a case of a stored XSS. When an attacker targets a compromised source (web site), the script is combined with a malicious script that persists when the code is executed. On the other hand, a reflected XSS will take a double route. First, the client is tricked, by ignorantly clicking on links. After this, the malicious code is sent to a vulnerable web site through request and to another client or the same client. In this way, a malicious script uses a genuine payload to gain the same privileges and permissions as a client. The third type of XSS attack is DOM Based. In this type of attack, a malicious script is present in a normal request and response. The only difference is that the malicious script is not directly part of the response from the server. Instead it is inserted into the DOM model of the response 6

7 c. Broken Authentication and Session Management There are a wide variety of threats with distinct properties. 'Broken Authentication and Session Management' involves hacking authentication details to a target web server. In the majority of cases, this type of attack has a serious impact on businesses. Once an attacker successfully hacks the authentication details to a web server, he/she can perform any operation that the compromised user has authorization to. The situations listed below involve this type of threat. 1. Poor implementation of session management including a session timeout that is too long Session management is extremely important in a web application. This is especially true when the solution has critical information which has to be authenticated and authorized. Owing to any vulnerabilities that are present while developing a session management module and authorizing a compromised session, the entire application or solution is at risk. If the end user is logging in from a machine (PC) that can be accessed by multiple users and a particular user does not logout, there is a serious threat to the security of the system. A long session timeout increases the vulnerability of this particular system. Any person accessing this PC after this particular user can do illicit activities. What makes a bad situation even worse is that there is no way to verify who the actual culprit is. 2. Session IDs that are a part of requested URLs One more sensitive aspect with session IDs is that they are a part of a URL request sent to the server. Owing to their presence as a part of the requested URL, any packet capturing tool can ensnare it. 3. User credentials are communicated through an unsecured channel and without proper hashing Given the prevalence of this situation in user management modules (login, update profile, update password, and so on), it is crucial to develop effective hashing algorithms to prevent hackers from having easy access to user credentials. d. Insecure Direct Object References Before we explain an Insecure Direct Object Reference, let us see what a 'Direct Object Reference' is. A DOR refers to any item that is linked directly to an 'Object' (a usable item in a solution) that is exposed, like record IDs. It is a very common practice to send IDs of DB records to the server to represent a user selection. Consider an example where the end user is selecting few items from a list of movie titles he or she wants to buy. In this scenario, the IDs are sent to the server for further processing. In this process, if the IDs being processed are seen packaged with the requested URL, then information about the current DB or tables is available to be misused by a hacker. An 'Insecure Direct Object Reference' refers to this type of record. One way to curb this type of vulnerability is to tag an each request with an authorization. e. Cross-Site Request Forgery Having seen how certain vulnerabilities can compromise authentication and authorization information (like broken authentication and authorization), we will now see how this information can be used by an attacker for illegal activities. 7

8 f. Security Misconfiguration Security configuration, especially in web development arena, is a critical area of concern. While developing the application to address other vulnerabilities, it is crucial to remember that ignoring this type of vulnerability can jeopardize the entire web application. Let us see how. Consider a brand new web application. After development, the next step in the process involves a regular QA and incubation stages. Generally, we are unconcerned about the deployment procedure. Despite the satisfaction experienced after we have configured the QA setup and the incubation (staging) setup successfully, there are genuine concerns for worry. Often, we forget that during development we might have inadvertently designed our web component (web servers, DB servers and so on) to allow development and debugging. The reasons for this type of vulnerability are flawed QA and incubation stages. Additionally, live deployment is affected by a flawed QA and incubation stages. As we have missed an opportunity to configure the components to mitigate the risks involved at different stages of deployment, the term Security Missed Configuration is a better term to describe Security Misconfiguration. An excellent example of a 'missed configuration' is a directory listing. The solution to this scenario is to remove access to the directory listing capability on the server, which might be required during development. The failure to do so will enable an attacker to not only download all content from the server but also experience multiple things like a reverse engineer code, identify loop holes, and exploit them. g. Insecure Cryptographic Storage Owing to poorly encrypted data, sensitive data like credit card details, passwords and personal details becomes available to an attacker. Standard encryption algorithms with a strong key are required to secure such data. If a DB query sends out decrypted data to the upper layers, then this can be a vulnerability. If the system can be compromised because of an SQL injection, then raising a query in a table with encrypted values will reveal record sets with clear-text. Salt Hashing is one way to increase security. Failure to Restrict URL Access URL access, an identifier for each web page, should be shared only when authentication and authorization procedures are completely foolproof. Each URL has to be checked thoroughly before a user is given access. The existence of this type of vulnerability reveals a faulty design and development of the presentation-layer.. The development team and the QA team have to check each page separately to confirm that only authorized users are able to access them. h. Insufficient Transport Layer Protection While communicating with a server, all sensitive communication, where critical data is involved, should be routed through a secure communication channel like SSL. The failure to follow this procedure can result in packets getting captured by attackers. Replaying these captured packets with the same session IDs can be used to obtain access to restricted areas or pages of an application. Proper SSL certification and exchange should be followed to overcome this vulnerability. Insecure storage of encrypted data is a vulnerability that involves the risk of an attack by internal attackers also. 8

9 i. Invalidated Redirects and Forwards Redirects are very common in a web application. As an essential part of the work flow, these redirects are based on critical transactions completed during the path of a work flow. During such redirects, precautions should be taken to see that the redirect page is validated against a known list of pages. The application can redirect to any given situation / work flow. 4. Secure Software Development Life Cycle SDLC (Software Development Life Cycle) is a process of planning and executing a software project. The stages involved in this process are listed below. Requirement gathering and elicitation (SRS) Architecture and design (HLD, LLD) Development / Implementation (CUT) System testing (QA) and maintenance. In the SDLC process for a web application, security plays a prominent role. During the development of a web application, a serious security concern can come up at the end of the SDLC process that requires major changes in the existing design. The result can be a delay in the development process or even a stoppage of the release. Both options are damaging to the development process. According to surveys and analyses conducted by many web security firms, standard SDLC procedures generally do not identify security issues till the system testing (QA) stage, which might involve tests like penetration. Discovering security issues at the QA (System testing) stage might prove to be very costly. A Secure SDLC is the recommended solution to overcome this obstacle. A secure SDLC involves looking at each stage of the SDLC process from a security point of view. In addition to introducing security features into the SDLC process and running it parallel to the standard SDLC process, a secure SDLC also involves training the entire project team to focus on security issues. Three methods for implementing a Secure SDLC are given below MS SDL (Microsoft Security Development Lifecycle) OWASP CLASP (Comprehensive and Lightweight Application Security Process) NIST An explanation of the methodologies mentioned above is out of scope for this paper a. Capturing security requirements While exploring security requirements, it is crucial to consider the entire gamut of requirements. Generally, this can be achieved by looking at how the end user interacts with the web application and the vulnerable points. For example, a requirement that reads 'There shall be a user login required to access the portal' indicates that we should establish a secure way to communicate user credentials while logging in and registering the user. If the user credentials are suspicious, then the following message should be displayed Broken Authentication and session management. b. Threat Modeling Threat modeling is a structured activity for identifying and evaluating application threats and vulnerabilities. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application. Threat modeling is not a method to review code. Instead it complements the security code review process. 9

10 The inclusion of threat modeling in the SDLC can help in ensuring that applications are developed with built-in security right from the very beginning. This feature along with the documentation produced as part of the threat modeling process can give the reviewer a greater understanding of the system. The threat modeling process can be divided into three high level steps: Divide the Application: The first step in the threat modeling process is concerned with developing an idea of how the application works and how it interacts with external entities. This involves creating test-scenarios to not only understand how the application works but also identify entry points to observe how a potential attacker could interact with the application. Other tasks include identifying not only assets and items/areas that the attacker might be interested in but also trust levels with regard to access rights the application will give to external entities. Classify and Rank threats: A threat can be categorized by applications like STRIDE. Another useful tool is the Application Security Frame (ASF) that defines threat categories like auditing & logging, authentication, authorization, configuration management, data protection in storage and transit, data validation, exception management. The purpose of categorizing threats is to identify threats not only from an attacker's point of view, (STRIDE) but also from a defensive stand point. DFDs produced in previous steps help to identify the potential threats from the attacker's point of view, such as data sources, processes, data flows, and interactions with users. Determine countermeasures and mitigation: The lack of protection against a threat might indicate a vulnerability that could be mitigated with the implementation of a countermeasure. Such countermeasures can be identified using threatcountermeasure mapping lists. A risk ranking is assigned to the threats. As a consequence, it is possible to arrange the threats from the highest risk to the lowest risk and prioritize the mitigation effort. The risk mitigation strategy might involve evaluating the business impact of these threats and the role they play in reducing the risk. Other options might include taking the risk, assuming the business impact is acceptable because of the compensating controls, informing the user of the threat, removing the risk posed by the threat completely, or, the least preferable option, do nothing. In any web application, threat modeling starts with data protection. We need to classify the data and its integrity inside the application. If there is a requirement for any data to be passed across a different layer, then there is a necessity for encryption. The choice between a standard STRIDE is a threat classification model developed by Microsoft for threats. It provides a mnemonic for security threats in six categories. The threat categories are: Spoofing of user identity Tampering Repudiation Information disclosure (privacy breach or data leak) Denial of service(d.o.s) Elevation of privilege encryption algorithm and a special encryption algorithm is available. Once data is identified, the next step is making a decision of how we can protect the data and track the flow of data throughout its life cycle. The best way is to create a data flow diagram with different security zones where data will be stored or transmitted. 10

11 Enterprise Network Secure Server Internet Location Device with Web Browser Request Protected Web Service Config Response Results Cloud Data c. Secure design and coding guidelines It is essential to not only define standards and guidelines for designing and coding with a focus on security but also develop a design that is both extensible as well as pluggable. The benefit of this approach is the ability to address vulnerabilities in batches instead of the entire software. The ease of working during development is an added advantage. There are many ways to achieve this. As we have seen in the 'secure SDLC' section, we need to develop this style of thinking in the development team. Having an eye for areas that can be breached and thinking like a hacker are extremely useful in developing an effective security apparatus. The first step in this process is outlining security requirements. It is best to start with most of the standard coding guidelines and extend them according to a particular application. Important guidelines, while developing a security system, are listed below. 1. We should keep the number of entry points to the minimum. Owing to this approach the size of the attack surface is reduced significantly. 2. Privileges should be established and checked at multiple layers. The ability to detect an attack improves remarkably and the difficulty of penetration increases significantly. 3. Preset settings should be configured. 4. Security should not be limited solely to key information like passwords. If these key elements are breached, the whole system is at risk. Multiple levels of interdependent information are a better option. 5. Generally, standard design patterns are quite risky. Analyze vulnerabilities associated with standard design patterns and address them if there is a requirement for a particular or a customized pattern. d. Ensuring security on 3P components The 3Ps, process, policy and procedure, are the foundation on which any idea or concept can flourish. While designing the security features of a web 11

12 application, we should follow these principles. There should be an efficient and organized process in place to implement the policy of the project management team, which has a well-defined set of procedures to ensure that security is not compromised at any stage. A process should be defined with the purpose of improving the efficiency of the workforce. A process can be defined based on vulnerable points of the software. Policy should be devised at management level with the goal of making security a key aspect of the project. The work force should be educated and trained in this policy. Procedure refers to any methods used to achieve the policy and process devised to improve the security of the project.. For example, in order to execute a static code analysis, we can opt for a plugin development tool that can be configured to run on each build. Alternatively, if there is continuous integration in place, then we can configure this tool to run or invoke scripts that can generate an analysis report and send it to all stakeholders (Manager, Leads). f. Secure deployment - IT security g. Releasing Security patches having 2 options for the cross tabulation report. In conclusion, while a conventional database takes around 14 seconds to execute a cross tabulation query, a solution based optimized query will gather data in less than one third of a second for 200 thousand respondents. 5. Popular Tools for threat modeling Microsoft's Threat modeling tool can be used to graphically design a security scheme for a web application / solution. Other tools include. Microsoft Free Threat Analysis & Modeling v2.1.2 My App Security Threat Modeler Trike e. Testing for security As stated earlier, security should be given importance at all stages of the SDLC. Given the critical importance of testing for security, it should be given the same importance as other tests. Test cases should be identified based on the existing security requirements. These tests should be repeated to help get the regression under control. There are a set of tools that can be tremendously helpful in testing the security related aspects of a web application. These tools include penetration testing tools. A penetration tool works on a proxy configuration that allows network traffic to pass through it and does ethical hacking to penetrate deep into the web application and report the results. There are many such tools available for use, both free and licensed. One of these tools used at Celstream is the 'ZAP Attack Proxy'. 6. Security review using static code review Static code review tools such as 'Fortify' can be used. Another tool called the 'VCG' can be used for analyzing code for standard vulnerabilities. Any typical code analyzer will provide the following options. 1. An option to select code files and folders. 2. An option to select the language in which the project is built. 3. An option to choose security standards that should be considered while scanning. 4. An option to provide reports in the form of a list. Each line item will describe the vulnerability tagged with it. 12

13 A security review team can review this report and guide the rest of the team to make the necessary alterations. This process should be repeated till a report without vulnerabilities is obtained. 7.Security review using runtime penetration testing As mentioned earlier, Penetration testing is a process where the web application is ethically hacked. This is achieved by configuring the chosen tool as proxy. This will direct all the requests made using browsers through this tool. After this, the tool progressively builds the required attack surface. After the attack surface is built, the attack starts. The tool starts the chosen type of attack on the built surface (entry points). The tool will try to send in all type of inputs to any user entry components. The tool is also capable of crawling web pages. Crawling is a process where the tool will try to identify any links available on each page and send requests to those pages. Any web service APIs' that are identified are triggered with random values for the parameters. Tools need extra input to execute a specific workflow-related attack. Scripts can be written to be picked up by the tool and execute the workflow. After the attack is complete, we can generate reports from the tool. This report can be analyzed. 8. Celstream's expertise Celstream has considerable experience working on the diverse aspects of web security. We have used tools, both free and licensed, to gauge security of web applications. We have followed secure SDLC principles in numerous projects completed with our clients. Tools like OWASP's 'ZAP Attack' and HP's 'Fortify' are important with regard to testing the security aspects of web applications. We have also used MS's 'threat modeling tool' for identifying possible vulnerabilities and designing effective solutions. Conclusion To conclude this white paper on the wide variety of aspects involved in providing security for web applications, we have to say that security and web applications are so interlinked because security plays an exceptionally important role in ensuring that web applications generate revenue for the, company. For a web application to be successful, it is essential that a security threat is not only discovered early but also eliminated in the shortest possible time. Educating project teams about development and QA teams about security, threats is, therefore, absolutely important. 13

14 References

15 About Us Celstream is an established product engineering services and technology solutions company with a rich heritage of collaborative, offshore and outsourced product development. Celstream supports the entire gamut of activities of product lifecyle - from concepts, design, implementation, validation to support, sustenance and monetization. We combine the best engineering talent, domain experience, world-class processes and advanced technology expertise to deliver high-quality products and solutions. We enable our customers to meet their business goals including increased agility, new revenues, competitive differentiation, deeper customer insights and new business models. Celstream 2017, Celstream Technologies Pvt. Ltd. All rights reserved. The information in this publication is subject to change. Specification and price change privileges reserved. Celstream is a trademark of Celstream Technologies Pvt. Ltd. Fortify is a trademark of Micro Focus., or its affiliates. OWASP, OWASP Zed Attack Proxy (ZAP), OWASP CLASP are brand/s is the property of the OWASP Foundation. All other trademarks are the property of their respective owners. 15