CHAPTER - 3 WEB APPLICATION AND SECURITY 3.1 Introduction Web application or Wepapp is the general term that is normally used to refer to all distributed web-based applications. According to the more technical software engineering definition is described as an application accessible by the web through a network. Many companies are converting their computer programs into web-based applications. Web applications are similar to computer based programs but differ only in that they are accessible through the web, allowing the creation of dynamic websites and providing complete interaction with the end-user. Web applications are placed on the Internet and all processing is done on the server, the computer which hosts the application [65] Figure 3.1 Browser and Website The rapid growth of internet has created many services, which have become an integral part of our day to today life. Web applications are used for making reservations, paying bills, and shopping on-line. With advent of Business-to-Business (B2B) and Business- 45
to-consumer (B2C) interaction, it is has become a necessity that information be exchanged in a secure and accurate way. Most of the web applications contain security vulnerabilities which enable attackers to exploit them and launch attacks. As a result of the attacks confidentiality, integrity and availability of information are lost. Information that can be read or copied by unauthorized users is called loss of confidentiality. Confidential information should be stored properly so that they cannot be disclosed. Credit card numbers, bank records, medical records, social security etc are example of this kind of information. Loss of integrity takes place when data is modified in an unexpected way. Attackers would intentionally tamper information resulting in loss of integrity of information. The loss of availability takes place when information is erased so that the legitimate user or authorized user would not be able to read it or use it. Loss of availability affects service oriented business which depends upon data. These attacks which are at application level, cannot be prevented using packet inspection firewalls which analyze individual IP packets for signatures or allow specific ports. What is needed is a mechanism which analyses the whole message stream. Attacks at application level differ from network layer attacks. Application level attack exploit vulnerabilities present in web application code and limitations of protocol like HTTP. Attacks at the application level cannot be stopped by most network firewalls and antivirus software programs. A network firewall normally leaves port 80 open for web server. It is through this port that the web application communicates to the user. If the attacker is able to access applications he may launch attack which cannot be prevented by the firewall. For example, consider a user who has a legitimate account at a banking system. He connects to his account by authenticating and establishing a valid session. If the user is injecting code to access unauthorized information of other users, then the network firewall or Intrusion Detection Systems (IDSs) will not be able to stop him. SQL injection is a very serious application level attack on web applications. 3.2 Architecture of Web application A basic understanding of web application architecture is essential before a discussion on 46
database security within web applications can take place. A high level view of a web application consists of five primary parts: the user, the firewall, the web server, the database server, and the actual database [66]. The user of a web application is responsible for the manipulation and insertion of data across the internet and into the web application. For the sake of simplicity, the assumption of a browser-based web application will be made. Static HTML pages are manipulated by the user and the data is submitted via an HTML request into the web application. Data specific to the user is submitted within this request through the use of HTML forms. After traveling across the internet, the request sent by the client s browser is first encountered by the web application s firewall. Assuming the request is legitimate according to the rules of the firewall, the request is passed on to the web server for processing. Figure 3.2 Architecture of a Typical Web Based System 47
The primary job of the web server is to dynamically generate and send static HTML pages in response to client requests. When a request is permitted into the web application by the firewall, it is parsed by the web server to determine what type of processing must occur. If a non-dynamic HTML page has been requested, the page is sent back to the client and the transaction completes. A page with dynamic components, such as PHP or ASP code, however, requires further processing. These pages are generated by the web server to create a customized static HTML page which is in turn sent back to the client. The dynamic portions of these pages are generated based off user-specific data submitted via HTML forms within the request. Dynamic portions of these pages allow for the creation of web pages containing real-time data, and are the backbone of any data-driven web application. The majority of this dynamic content is stored within databases and must be requested from one of the most important components of a web application, the database server. The job of the database server is to accept requests for data from various components of the web application and retrieve this data from the database. The database itself is managed directly by the database management system, or DBMS, and is not directly accessible. Requests must be sent to the database server, a component of the DBMS, which retrieves and delivers data from the database. These requests are sent according to a certain style and syntax, known as the Structured Query Language, or more commonly by its acronym, SQL. SQL is an extensive language that allows for efficient retrieval of specific data from within the database. In the dynamic component of the web page, SQL queries are created based off of the data contained within the HTML request that was sent from client browsers. These SQL queries are passed to the database server, where the query is parsed and the resulting data is retrieved from within the database. 3.3 Who Needs Web Applications and Why? There are many entities that require applications for the Web-one example would be Business-to-Business interaction. Many companies in the world today demand to do business with each other over secure and private networks. This process is becoming increasingly popular with a lot of overseas companies who outsource projects to each 48
other. From the simple process of transferring funds into a bank account, to deploying a large scale Web services network that updates pricing information globally, the adoption of a Web applications infrastructure is vital for many businesses [67]. 3.4 Web Application Model The Web application model, like many software development models, is constructed upon three tiers: User Services, Business Services and Data Services. This model breaks an application into a network of consumers and suppliers of services. The User Service tier creates a visual gateway for the consumer to interact with the application. This can range from basic HTML and DHTML to complex COM components and Java applets. The user services then grab business logic and procedures from the Business Services. This tier can range from Web scripting in ASP/PHP/JSP to server side programming such as TCL, CORBA and PERL, that allows the user to perform complex actions through a Web interface. The final tier is the Data Service layer. Data services store, retrieve and update information at a high level. Databases, file systems, and writeable media are all examples of Data storage and retrieval devices. For Web applications, however, databases are most practical. Databases allow developers to store, retrieve, add to, and update categorical information in a systematic and organized fashion [67]. 3.5 Phases in a Web Application Project The Web application development process has four phases: I. Envisioning the nature and direction of the project II. Devising the plan III. Development IV. Testing, support and stability 3.5.1 Envisioning the Nature and Direction of the Project: In this phase, the management and developers assigned to the project come together and establish the goals that the solution must achieve. This includes recognizing the limitations that are placed on the project, scheduling, and versioning of the application. By the end of this phase, there should be clear documentation on what the application will achieve. 49
3.5.2 Devising the Plan: In this phase, team must determine the "how s" of the application. What scripting language is most appropriate, which features must be included, and how long will it take? These are some of the questions that must be answered through this planning phase. The main tangents at this point are the project plan and functional specification. The project plan determines a timeframe of events and tasks, while the functional specification outlines in detail how the application will function and flow. 3.5.3 Development: Once the project plan and functional specification are ready, a baseline is set for the development work to begin. The programmer/s or Web developer/s begin coding, testing and publishing data. This phase establishes the data variables, entities and coding procedures that will be used throughout the remainder of the project. A milestone document is prepared by the development team, which is then handed to management for review. 3.5.4 Testing, support and stability: The stability phase of the application project mainly focuses on testing and the removal of bugs, discrepancies and network issues that may otherwise cause the application to fail. It is here that policies and procedures are established for a successful support system. 3.6 Planning for a Successful Web Development Project In order to drastically minimize the risk of project failure, there are four approaches to minimize the risk [67]. 3.6.1 Identify Business Logic and Entities: Start by gathering information on everything you have. If you are going to be working with databases, begin by enumerating how many entities will be used in the business logic. For example, if your program implements sales data, a sales ticket would be an entity. Once you have identified all your entities, establish a clear guideline for their relationships. This can be done via presentations, flowcharts or even reports. 50
3.6.2 Create a Functional Specification and Project Plan: This part is the most important part of the project. Functional specifications are a map, or blueprint for how you want a particular Web application to look and work. The specification details what the finished product will do, user interaction, and its look and feel. An advantage of writing a functional specification is that it streamlines the development process. It takes discrepancies and guesswork out of the programming process, because the level of detail that goes into the plan makes it possible to minimize the misunderstanding that s usually associated with project mishaps. Once the functional specification is finished, a project plan must be devised. A project plan is a timeline of tasks and events that will take place during the project. The project or program manager is normally the person who creates a project plan, and their primary focus is to detail task notes while being able to accommodate scheduling and resource information. 3.6.3 Bring the Application Model into Play: As discussed above, the application model consists of 3 tiers The User, Business and Data service tiers, each of which serves a substantial purpose. It is always best to start with the data tier, because you have already identified your entities and understand their relationships. The data tier can be an SQL server database, a text file, or even the powerful and robust Oracle. Create tables, relationships, jobs, and procedures depending on what platform you have chosen. If the data is a warehouse (i.e. the data already exists and does not depend on real time interaction), then make sure that new and additional data can be added securely and in a scalable fashion. Using views in SQL server/oracle can improve dramatically the productivity and performance of your application. They increase speed because they are "stored queries" that do not have a physical existence. The Business services tier is the heart of the application. It involves the implementation of business logic into the scripting or programming language. At this stage, make sure you have already set up your environment for testing and debugging. Always test on at least two instances in your application, after all, what may work perfectly for you, may not do so well on other platforms or machines. ASP, XML, PHP, JSP and CGI are some 51
examples of server side scripting languages used at the business service level. Whichever language you choose, make sure that it s capable of handling all the business logic presented in the functional specification. 3.6.4 Develop a support scheme: Being able to support and stabilize your application is very important. Define a procedure call for cases of failure, mishaps or even downtime. Give your customers the ability to contact you in the case of an emergency relating to the program. A good example of a support scheme is a ticket tracking system. This system allows users to file cases pertaining to a support request and the support team, then makes the case track able. This means that the request is identifiable by a unique code or number. Although ticket-tracking systems are normally used by hosting companies or large scale ASP s (Application Service Providers), they still serve a valuable purpose in helping keep the application stable. 3.7 Web Service Security Functions Web service security standards, functions, and technologies continue to evolve at a rapid pace, driven by changes in the types of software attacks, community stakeholders, and Web services policy decision makers. This section describes several current and emerging standards, initiatives, and techniques aimed at improving the security of Web services. Many of the concepts used in securing Web applications are useful for understanding the security of Web services [70]. 3.7.1 Service-to-Service Authentication: Authentication is required to limit access to resources, to identify participants in transactions, and to create seamless personalization of information based on identity. A means of sharing the fact that authentication has been performed successfully is necessary to support single sign-on, allowing users to authenticate with one system and use other services and applications within a Service Oriented Architecture (SOA). Service-to-service authentication can be performed using a variety of methods, from HTTP-based token authentication to SSL/TLS-certificate based authentication, or by passing tokens along with the SOAP request. The HTTP and SSL/TLS-based methods are performed below the SOAP message layer and are transparent to the Web services involved, while SOAP-based token protocols require interaction between Web services. 52
Token-based Web services authentication is usually performed using the Organization for Advancement of Structured Information Standards (OASIS) Web Services-Security standard which supports tokens based on a variety of authentication standards: usernames, X.509 PKI certificates, Kerberos tickets, or SAML assertions. Web Services-Security libraries are available for most of the widely used Java and.net Web services development platforms. When a service provider attempts to access a remote Web service on behalf of a user, it should send an authentication token within a Web Services-Security message. These tokens convey that the initiating entity (e.g., a user or requester) has been authenticated and provide information about the entity, such as the authentication mechanism, time, and possibly subject attributes that may be applicable. Often, these tokens take the form of a SAML assertion. 3.7.2 Identity Management: Identity management for Service Oriented Architecture (SOA) encompasses the full range of identity-related events, information, and documents by which an entity s identity is verified, identity documents and credentials are issued to the entity, and entity identities are authenticated at point of entry into the SOA. In the SOA, an entity s identity forms the basis for both authorization and trust [69]. An Identity Management System (IDMS), such as that pictured in Figure 3-3, is responsible for verifying the identities of entities, registering them, and issuing them digital identifiers. For example, users who wish to gain access to many e-commerce sites often need to provide only a valid email address and a credit card number. Once an entity has been issued a digital identifier, that identifier can be used within that organization to associate other information with the entity, such as role and authorization attributes. The identifier may also become part of the digital credential that authorizes the entity to access different resources in the SOA. Once registered, an entity must provide a portion of its credentials sufficient to authenticate that entity s identity. Again, different organizations have different policies for what constitutes sufficient authentication credentials. Many e-commerce sites require the entity to supply a username and password; other organizations may require the entity to submit an X.509 certificate. 53
Figure 3.3. Identity Management Overview After the entity s identity has been authenticated, the policy decision point (PDP) of the system or resource to which it desires access must determine whether the nowauthenticated entity is also authorized to access the resource. To perform authorization, the PDP relies on privilege management and attribute management. Privilege management enforces the policies that govern entity access. The policy decision to allow or deny access may be based on a single entity attribute such as the entity s role, or it may require a combination of fine-grained attributes such as the physical location of the entity, its currently active role in the system, and its clearance level. The attribute management system uses the entity s digital identifier (issued by the IDMS) to locate 54
and retrieve those of the entity s attributes that are required by the privilege management policy. 3.7.3 Establishing Trust between Services: For Security Assertion Markup Language (SAML) or Web Services-Security to be useful on a large scale, trust relationships need to be established between remote Web services. A signed SAML assertion or Web Services-Security message is of no use if the receiver of the assertion cannot guarantee that the information asserted is trustworthy. 3.7.4 Describing Web Services Policies (WS-Policy): Web Services Description Language (WSDL) describes how to communicate with a Web service by detailing the protocol bindings and message formats the Web service expects. In many cases, knowledge of protocol bindings and message formats is not sufficient for requesters to dynamically bind to the provider. WSDL is limited to describing what needs to be placed in the message itself; it does not specify what type of metadata should be supplied, such as how the message will be authenticated or what portions of the message should be signed. To this end, Microsoft, IBM, BEA and others developed the Web Services Policy (WS-Policy) Framework, which allows providers to express the capabilities, requirements and characteristics of the Web service [70]. 3.7.5 Distributed Authorization and Access Management: Given the distributed nature of Web services architectures, managing authorization and access control credentials for users in a SOA environment can be challenging. This section describes a number of traditional and emerging models and practices that may be extended to capture, manage, and enforce access control decisions for authorized users. 3.7.5.1 Authorization Models: This section describe the authorization models most relevant to access management in a SOA, namely role-based, attribute-based, policy-based, and risk-adaptive access control. While role based access control models may be familiar to most software designers and developers, knowledge of the other models can provide a perspective on the direction in which Web services access management is heading. Role-based access control (RBAC): RBAC is an authorization mechanism that associates a set of access privileges with a particular role, often corresponding to a job 55
function. With RBAC, all user access is mediated through roles. RBAC simplifies security management by providing a role hierarchy structure. In addition, RBAC has extensive provisions for constraints on user access based on administrator-defined relationships. This feature makes it possible to implement complex controls such as separation of duty. Attribute Based Access Control: An access control approach in which access is mediated based on attributes associated with subjects (requesters) and the objects to be accessed. Each object and subject has a set of associated attributes, such as location, time of creation, access rights, etc. Access to an object is authorized or denied depending upon whether the required (e.g., policy-defined) correlation can be made between the attributes of that object and of the requesting subject [68]. Policy-Based Access Control: Policy-based access control (PBAC) is a logical and somewhat bounded extension of ABAC that is useful for enforcing strict environmentlevel access control policies. PBAC introduces the notion of a policy authority, which serves as the access decision point for the environment in question. PBAC leverages the granular policy rule functions inherent to ABAC; it focuses more on automatically enforcing mandatory access controls (MAC), which are traditionally much more bounded than discretionary controls [70]. 3.7.5.2 Enforcing Least Privilege for Services: Trust and privilege are not synonymous. This said, trusted objects are often used to perform privileged functions. Least privilege can and should be applied regardless of what access control methodology is in use. In a Web services environment, each Web service should be designed to not request or expect to obtain privileges that exceed the minimum privileges it needs to perform its current operation. 3.7.6 Confidentiality and Integrity of Service to Service Interchanges Although transport layer security mechanisms are provided through using secure transport protocols such as SSL/TLS, message layer security of XML is still needed for the following: 3.7.6.1 End-to-End Security: Secure transport protocols can assure the security of messages only during transmission. Because messages are received and processed by 56
intermediaries, secure end-to-end communication is not possible if these intermediaries are not completely trusted. 3.7.6.2 Transport Independence: Even if all the communication links are secure and the intermediaries can be trusted, security information such as the authenticity of the originator of the message needs to be translated to the next secure transport protocol along the message path. This could be tedious and complex, which may lead to security breaches. It is important to deal with the security concerns at the message layer independently of the transport layers. 3.7.6.3 Security of Stored Messages: Once a transmission is received and decrypted, transport layer security does not protect data from illicit accesses and alterations. In situations where messages are stored and then forwarded, message layer security is necessary. 57