Web Application Security Testing - Part1

Web application and Client-Server, are they same? This question is very common in software testing interviews, if you are part of some e-groups related to testing, you might have heard it many times from different people. There are numerous differences in Client-Server and Web application architecture. As a tester if you are testing Web applications, it is important to understand what Client-Server architecture is and how Web is different from traditional ClientServer architecture. Web is a specialized version of client server network, but it has got noticeable differences. In client server network, computing resources are conserved by delegating complex and time consuming task to powerful, expensive computers called server. These server machines are much more powerful in terms of large storage and computing power. They do all the computing and delivers result back to the machines called client over a communication path. Thus client-server architecture comprises of server, client and communication path connecting them. If you see at the lower level, client server architecture is not that simple. In order to connect two computers, you need network level protocol, you need proper software at client side and server side to send and receive data over network. You need to take care of data loss during transmission, bandwidth issues, dropped connectivity etc. Most of these issues are already addressed by protocols like TCP/IP, UDP, ARP etc. and developers face very little problem in implementing them. These protocols are backbone of the client server architecture. WWW was developed on top of existing client server architecture. It came into existence as a replacement for FTP and email as a mechanism of sharing files and data. New development in servers to handle more requests, new client software to connect and browse resources on server; new development like HTTP, HTML etc fueled the growth of Web. Main component of the Web architecture is the Web Server, which can serve request from any client. Initially, web started serving static content and soon it was explored for the possibility of doing much more than just static content. Even though Web is built on top of client server, there are noticeable differences. For example

Web is a special case of client server architecture in which fat clients are used to communicate with the server using variety of protocols and standards like HTTP, HTML, XML, SOAP etc. In client server architecture, both client and server exist within the walls of a single company, thus operates in a protected environment. Clients in that case become the trusted user. Web is different, since client can connect server from anywhere thus not a single connection can be treated as trusted. Because client server is typically within a companys firewall, issues related to security are not as important as in Web applications.

In client server architecture, clients are controlled as in who can access, how clients will communicate and use servers resources etc. In Web, mostly anyone with a browser can connect to the Web. In client server architecture, every client is known; every request received by server will have information on who originated this request. In Web, users are anonymous thus pose a greater security risk. Web gives more opportunity to malicious users to tamper data at the client side as well as at the network level. Chances of data being tampered in the traditional client server architecture are much lesser as compare to Web. Number of clients that can be connected to the server is predictable and can be controlled in the traditional client server, but it can not be controlled in the Web. Clients are much more controlled in client-server. Which OS they will use, which platform they will run on, what browser will be used every thing can be controlled. In comparison to that, nothing can be controlled in Web.

Because of the fact that both are different, testing applications in client server, or web will also be different. The main areas where the testing gets affected can be summarized as:

Business Logic: Mostly in the cases of Client-Server client side business logic needs to be tested which is mostly not needed in for the web-based applications. Platform / OS Dependence: The web based applications are O/S independent; they just need to be tested on different browsers. The Client-Server applications depend upon the Platform/ OS used, which accentuate their testing on different Platforms and OS. Scalability: Web based Application have to be tested for performance against thousands of simultaneous users. This number will be considerably less for Client Server application Security: This forms an integral part of web based applications but it might be relaxed just a bit for Client Server applications. The reason for this relaxation is based on the fact that the in case of Client-server interaction is taking place mostly between the trusted/known sources which is not the case for web based applications.

In a nutshell it can be stated that although web-based applications are a special case of clientserver applications, yet their testing differ in many areas. All the areas identified above need to be addressed adequately in your testing, specially security since every client connected in the web environment is a potential threat to the system. Hope with this article you can appreciate the difference between client-server architecture and web application architecture. Also, how testing applications based on these architecture is different from one another. Importance of security testing in the web application testing is also established in this article. Next article will take this subject further and discuss various techniques and tools to perform security testing for web applications.

These articles are influenced by the book ( How to Break Web Software from Mike Andrews and James A. Whittaker ) I have recently read and should be a good read for you if you need information on web application security testing.

Web Application Security Testing - Part 2

I hope that you have already read first part of this article and familiar with the concept of how web applications are different from traditional client-server applications. If you have not, you might find it useful to read Part-1 as well. In this part we will explore what kind of information is available to the client? What kind of information can be gathered from the pages which client can access? How validation is important to ensure proper security for the web application? What are cookies and how web applications use them? It is very important in web application security testing to gather as much information about your application as you can. You need to find out how people outside your organization will access your web application and what kind of information they can access. Typical information that will be available to any person outside your organization could be categorized as

Comments & Sensitive information embedded in the HTML source code Error messages generated at the server and HTTP response returned. Application error message

During web application development, it is very important to think about these aspects. Comments or sensitive information can be very useful for you while developing and maintaining the code, but if it is accessed by malicious user it can be dangerous. Similarly, detailed error messages given to improve usability can results in the security loophole. HTML source present on the client side can be an excellent source of information for the attacker. It is very easy for everyone to view HTML source code and since it is not compiled, there is no way to hide HTML comments. For testing web applications for security, you should look for the sensitive information like passwords, usernames, database names, connection strings etc. As a person responsible for security testing you need to make sure that sensitive information is not present in the HTML source code. In order to start attack on any web application, it is important to know how its pages can be accessed, what kind of data and parameters are passed from one page to another. You can keep an eye on the URL for this purpose and look for key-value pairs. You should always consider creating page map of your site containing this information. You can use tool or can create it manually by navigating to all the pages and making appropriate maps. After you have created this page map, you can search HTML source for specific strings containing information related to HTML comments, Application Comments, IP Address, E-Mail Address, SQL Queries, Database Connection Strings, Hidden input fields etc.

If you try to change parameters selected during this process and resubmit the request, you can find interesting information in error messages. Sometimes server or application throws overly helpful error messages which can give subtle hints to the attackers. For example on supplying invalid password during login process if system throws error like 'invalid password' , it essentially means that username is proper. Page map created earlier can also help you in guessing file names and directory structure present on the web server. Using this technique you can access files for which there is no link present on the pages, or which is not intended to be visible to the user. You must always check for the presence of any pattern in file names and location. Files which should not be viewed by clients should be located in places not accessible to the clients. Using this technique of educated guessing, malicious users can even access admin or control panel of the website, which usually runs as a separate sub-site or run on a different port. These type of loopholes can be identified easily by tools like port scanners and other brute-force tools. Vulnerability of the web application can also be exposed by manipulating UI controls. For example, you might have used websites containing list boxes to take user input. Reason for providing list box is to make sure that client do not choose any other option apart from whatever is supplied in the list. It is very easy for development team to make this assumption and not do any other form of validation. What they fail to realize is that, these values can be changed by making changes in the page source even request can be tampered on transit using appropriate tools. Also if validations are present at the client-side, it is still possible to bypass those validations. This could be achieved either by disabling the java scripts or saving a local copy of the file and removing those validations. To safeguard from these vulnerabilities, it is essential to make sure that validations are present on the server side as well. Another thing that should be checked at the client side is cookies. For people not familiar with cookies, cookies are small files of textual data that a web application writes on a client's hard drive. Web application can reuse this data on subsequent visits. Cookies can be delivered by web application using either persistent/non-persistent and secure/non-secure mode. Cookies can be used for personalization or making sure that information is not accessed after it is expired. There are many ways in which cookies can be used. Cookies are normally stored at predefined location with predefined formats. If your application relies on cookies for any functionality, it is essential for you to make sure that tempered cookies can not be used with your application. Hope after understanding the different ways in which security can be compromised, you will appreciate the importance of security testing of web applications. In the next article, we will explore how data supplied by client can be tempered and servers can be attacked. You can read more articles on software testing in our article section. You can suggest topics of your interest here , we will try to provide information on those topics as well. These articles are influenced by the book ( How to Break Web Software from Mike Andrews and James A. Whittaker ) I have recently read and should be a good read for you if you need information on web application security testing.

Web Application Security Testing - Part 3

I hope that you have already read first two parts of this article and familiar with the concept of how web applications are different from traditional client-server applications and what kind of information can be collected from the client. If you have not, you might find it useful to read Part-1 and Part-2 as well. In this part we will explore how user supplied data can attack your application. We will explore information related to SQL injection, Cross Site Scripting, Directory Traversing etc. Cross-site Scripting ( XSS ) is a mechanism of presenting user with a fraudulent web site content. Web sites often echo the input data that is entered as some other places with in the application, for example users postings in forums. Sometime postings in forum can also include HTML as well. This HTML, along with the formatting information can also contain client side scripting, which can be dangerous since it will have access to the content of current page. Client side scripting can even steal user's cookies. This type of cross site scripting can be used in places where user write something which is available to all the users. For example, book reviews, blog comments and so on. Another mechanism of using cross site scripting is called reflected crosssite scripting. In this technique, attacker can embed the script into CGI parameter of a URL. When user clicks on the link, real page is loaded and its content changed by the script that is embedded in the URL. Cross-site scripting attack is best suited for situations when user supplied input data is echoed back the other users. Mostly, this attack exploits the facility of providing user input in HTML format and insert malicious scripts with in <SCRIPT> ... </SCRIPT> tags. Apart from direct SCRIPT tag, tags like HTML, BODY, EMBED, FRAME, FRAMESET, IMG, LAYER, META etc. are also known to have this vulnerability. In fact, any tag which support attributes like STYLE, SRC, HREF etc. are known to be vulnerable. The best way to protect against this attack is to filter the contents of user supplied data. It should be noted that while filtering, white-lists approach (Allow only trusted code) should be used instead of black-lists approach (Block code with specific tags and allow rest), since it will not cover new vulnerabilities. SQL Injection is probably one of the well known vulnerabilities in web applications. In this vulnerability, SQL queries can be injected in the form of user input data which can results in number of insecure behavior. For example, on a login page if your application is not protected against SQL injection, you can use it to get all the user names and passwords stored in the database. This technique is mostly used in situations where SQL query is dynamically generated using the data or parameters supplied by user. This vulnerability can be extremely dangerous since SQL is often used for authentication, authorization, billing etc. Any user input, which becomes part of a SQL query is subject to a possible SQL injection vulnerability. This attack require sound knowledge of database schema for your application and how queries are constructed. Because of the nature of attack and possibility of major threats

associated with the attack this is one attack, you should always check in your application. Consider following example to appreciate how serious SQL injection attacks can be Suppose your application takes username and password and construct query like this Select * from Account where username = 'username' and password = 'password' ; In this query, username and password are passed as parameter and will be replaced in the query. If you pass normal information it should work fine. But how will your query look if you give your username as testuser'-Select * from Account where username = 'testuser'--' and password = 'password' ; Now if you look closely, '--' is SQL comment operator, and effectively it has converted this query into this Select * from Account where username = 'testuser' You can understand effect of this query now. You can think of even more serious usage, for example getting list of all the users along with password may be? Yes it is also possible if your application is not tested against this vulnerability. Similar to most of the attacks, the best way to protect against this attack is proper filtering of parameters at the server side. Another popular attack in web application is Directory Traversal, in its simplest form, malicious user determines the location of restricted files and views or execute them. Problems associated with this could be ranging from breach of privacy to controlling or modifying the site content. In its simplest form attacker can just guess the file names, directory name and get those files which are residing on the server, but not public as of now. Directory traversing can also reveal sensitive information if your application and server is not protected properly. Consider this URL http://www.somedummyURL.com/getinfo.asp?item=getinfo.asp This URL is requesting itself, in cases like this web server will display source code of getinfo.asp and that can give considerable information to attacker including database connection strings, password, business logic etc. This attack can be dealt in two ways. To restrict web application to serve pages from only web root directory / subdirectories and by using Access Control Lists. Hope this information was useful to you and can be used to do security testing for your web application. In the next article, we will explore language specific attacks and different mechanism of attacking servers.

You can read more articles on software testing in our article section. You can suggest topics of your interest here , we will try to provide information on those topics as well. These articles are influenced by the book ( How to Break Web Software from Mike Andrews and James A. Whittaker ) I have recently read and should be a good read for you if you need information on web application security testing.
Web Application Security Testing - Part 4

This article is fourth article in the series of web application security testing. In the first three articles, we have built the base by making you familiar with the difference in web application and client server application, how gathering data about the application is important and popular attacks like SQL injection, Cross site scripting and directory traversing. In this part we will explore how to attack server by exploiting the known limitations of language in which they are implemented. Broadly, we will cover buffer overflow, Canonicalization and Null strings related attacks. Buffer Overflow Buffer overflow is probably one of the most notorious and oldest attack. This vulnerability has been around for more than three decades. In the very simplistic term, A buffer overflow is the result of stuffing more data into a buffer than it can handle. This vulnerability is mostly exposed in situations where programs processing the input data is failed to check the size of input data it is processing. You might think how it can affect security of the system ? When input data is larger than the space allocated for it, it overflows into other memory location on the execution stack. This overflow results into the corrupted memory locations in the execution stack because it overwrites the data present in the execution stack. In most cases, application will crash because of this, because it can not handle the corrupted execution stack. This vulnerability becomes very dangerous when input data overflow into memory that will be used in choosing which instruction to execute next. In carefully crafted data, input data can become the instruction to the computer. This causes input data to change the execution sequence of the machine and allow attacker to run arbitrary code on the web server, This vulnerability is exposed most notoriously by the worms such as CodeRed, Nimda, Slammer etc. If you are interested more in the topic, you might find reading Smashing the Stack for Fun and Profit very interesting. It is very easy to conduct this attack, you need to give input much larger than your program is designed to handle. You also need to make sure that you do not rely completely on the client side validation. You need to supply large input data by bypassing the client side validation and ensure that server side code handles this as well. If your web application or environment is not secured against this attack, it can crash your web server or operating system as well. You can also use

tool such as SPIKE Proxy for automated buffer overflow testing of Web Application. When using any tool for this testing, be aware of the false positives. This vulnerability, if present in your web application can have very dire consequences and hence it is very important to make sure that you filter out all the false positives generated from any tool. It is very easy to protect your application against this attack. You can either find out the size of data and allocate memory accordingly. Alternatively, you can also terminate input data at a sensible size and ignore everything else. Canonicalization Before finding out how security of your web application can be compromised by canonicalization (A lso known as C14N ), it is important to understand the meaning of canonicalization. Canonicalization means ensuring that all data is represented in a standard, common form. In the absence of canonicalization, validation might miss some important attack. C14N is needed, because we need to encode certain characters because they have extended meaning in some context. For example, a simple white space character sent by browser is converted in '+' because white space can cause break in CGI parameter sequence. There are many character sets like ASCII, UNICODE or UTF-8 in use. There could be chances of security risk when browser is working on one set of character representation and server is working on another. For example, standard characters / is represented as / in HTTP but it can also be represented as %5c and %c0%af . This vulnerability was exposed in IIS 4 or 5 Web server with commands which will potentially allow you access command prompt and execute any commands on that. Another level of complexity can be introduced by double encoding where characters used in encoding are encoded again. Along with canonicalization, vulnerabilities related to NULL strings can also have major security loop holes in your web application if left undetected. NULL string can also be represented by \0 or %00 . NULL strings related vulnerabilities can become security loop holes because different languages treat NULL characters differently. In some languages or libraries, NULL character added in the end can or can not have any effect. Best way to deal with this type of attack is to make sure that NULL characters are stripped from from the original data at the first opportunity. Normally, they do not serve any purpose. Though attacks described in this articles are well known and most of the application and languages can already have protection for these attacks, still it is our responsibility to make sure that there is no security loophole in the web application. In the next article we will discuss how servers can be attacked and issues related to authentication and privacy. These articles are influenced by the book ( How to Break Web Software from Mike Andrews and James A. Whittaker ) I have recently read and should be a good read for you if you need information on web application security testing. Web Application Security Testing - Part 5 In the earlier articles of this series, we have concentrated on errors

or mistakes that should be avoided at the code level and importance of data validation at client side and again on server side. If you have not read earlier articles in this series, you might find it interesting to read earlier articles covering many concepts related to web application security testing. In this part we will establish the importance of securing our environment as well for providing complete security to web application. Web application is hosted in the environment, which is accessible from the out side world. Client interact with the server and database, if proper care is not taken vulnerabilities in the environment can be exploited and as a result security will be compromised. We will discuss, different vulnerabilities related to the environment on which web applications are hosted like stored procedures, command injection, fingerprinting and Denial Of Service. Stored Procedure Stored Procedures are pre-written SQL queries that are supplied by the data-base vendor or third party custom procedures written in-house and integrated into the database. In general, Stored Procedures can be used to improve security and performance of web application, but you need to make sure that you use them with proper care and give only minimum necessary privilege to the user. In Microsoft SQL Server, many of the stored procedures integrate the database into operating system. This can allow users with sufficient privileges to create login, schedule tasks and run command line programs which can be very dangerous. In Oracle, this functionality is not available out of the box, but developers can use either Java or PL/SQL languages supported by Oracle to build this functionality. If you are using Microsoft SQL, one of the most dangerous stored procedure to look for is xp_cmdshell. This is an interface from database to operating system that can allow attacker to run arbitrary commands on the web server machine. To use this stored procedure, you need to pass following command as a separate query EXEC master.. xp_cmdshell 'any command' EXEC is the command used to execute this stored procedure and master.. is telling that this stored procedure is not part of current database. Similar to xp_cmdshell , there are many built-in stored procedures for accessing registry, file system and so on. Protection against this vulnerability lies with the proper access permission. Ideally, every user should be granted permission for only what he needs and everything else should be restricted. Command Injection As suggested by the name, command injection is very much similar to the SQL injection. In SQL injection we inject any arbitrary SQL query along with the one intended. Similarly, in command

injection we inject additional commands along eith the one intended. Command Injection allows an attacker to easily execute shell commands by piggybacking them off the initial command. This target is applied mostly at places where input is directed to operating system commands or executable programs that resides on the server. Probability of this vulnerability's presence might be more on the UNIX operating systems because there are many small programs that can be executed from the command line and developers can decide to use them directly as well. Once you identify place where commands are being passed to the operating system you can now try to piggyback commands after semi column or forcing new line characters. System will treat anything after semicolumn a different command rather than same command. You can also use | ( pipe ) and > (greater than) character to redirect the output to some file using this technique. Proper safeguard from this attack is obviously, input validation. Along with input validation, exposure to this attack can also be minimized by running the web server as a low-level restricted user. Because all code and system call execute with the permissions of the user account that initiated them, it is wise to ensure that the web server is running as a user that can perform only limited operations. Server Fingerprinting Along with all the good knowledge Internet brings to everyone, it also makes it possible for everyone to know about the existing vulnerabilities in different operating system, databases and web servers. There may be chances that some one is still running older version of IIS and Apache, and most of the attackers know vulnerabilities present in these systems. There could be valid business reason for many people to still use the older version. One of the very important piece of information for any attacker is the knowledge of your web server. If your attacker have information about the web server it can be fairly easy to find out vulnerabilities present in that particular web server. Attack to identify what kind of web server you web application is running on is called finger printing. Idea is to find the version of the Web server and find a known exploit for it. You might think that getting version number is fairly easy since it is specified in one of the headers for HTTP response. Fortunately, these responses can be changed by changing the configuration file on the web server. Nevertheless, you should always make sure that this is indeed changed. You can use tools like HTTPPrint to find out information about web server with some confidence. The only protection against this attack is to know what your attacker already knows and proactively make sure that your environment is protected against known vulnerabilities. It is always a good idea to keep an eye on sites like http://www.securityfocus.com and http://www.osvdb.org to get information about the known vulnerabilities. Denial Of Service

Every time you request some operation on your web application there are many processes which happens in the backend. Every request on the web server consume some resources. If an attacker floods web server with many requests and consumes all its resources so that web application becomes unavailable or unresponsive to new requests, it is called Denial of Service ( or DOS ) attack. To perform this attack, you need to find out the places where web application is taking longest time to return the result. Places where your application is accessing databases or doing complex computations. Attacks like SQL injection can also be used to inject complex SQL queries which can result in Denial of Service. Another approach could be to request a page but be slow in accepting data in response. Web server will keep connection open until it receives everything. If you can have many connections like these, eventually server will run out of the number of connections it can open and deny service to any new connection request. It is worth noting here that according to the Internet standards, it is not possible to make more than two connections from the same browser to web server. You will need to write simple script to forks off multiple child processes to request same URL. You also need to check effect of these requests on your web application. It is very difficult to protect against this attack. Normally clustering and load balancing is used to make sure that large number of requests are handled appropriately. Generally it is not considered a good approach to rely only only on load balancing and for sophisticated high-volume site it is not uncommon to find Intrusion Detection System and Bandwidth management solution to counter this attack. Hope you found these articles interesting and they gave you some insight on different aspects related to web application security testing. In the next article, we will explore security aspects related to authentication and web services. These articles are influenced by the book ( How to Break Web Software from Mike Andrews and James A. Whittaker ) I have recently read and should be a good read for you if you need information on web application security testing.
Web Application Security Testing - Part 6

This is the last article in the web application security testing series. In the earlier articles we have seen many interesting vulnerabilities like SQL injection, Cross site scripting, vulnerabilities related to the environment and so on. If you have not gone through these articles, you might find it interesting to read them in out article section. In this part we will explore the security issues related to Authentication and Web Services. Authentication is the core of many web applications, since in the WWW world, we need to check connection from every client to make sure that it is not from a malicious user. Similarly Web services are common place these days, and most of the common applications that you use on daily basis, might be using web services. Threats associated with the web services are very much different from what we have already seen.

Authentication can become vulnerable because of various reasons. As a tester, certifying security of your web application these are the things you should consider Fake Cryptography Traces of cryptography and securing information on the transit can be traced back to hundreds of year. It becomes even more important when most of our personal data is on the internet for everyone to view, if it is not encrypted properly. There are many ways in which data can be encrypted thus making it difficult for any one on the internet to understand it. Often programmers also rely on weaker encryption technology or use their own cipher substitution, which might be very easy to break for the seasoned hacker. It is also possible to get some idea about the encryption technologies being used by looking at the encrypted data. For example, presence of only alpha-numeric characters and '=' can indicate that base64 encoding is being used to hide the data. Similarly, if you have access to the data being encrypted and encrypted data, you can make minor change in the data and analyze the encrypted data to find out if substitution cipher has been used. The only way to protect against this attack is to use well known security algorithms like RSA, Triple DES etc. as oppose to inventing something new. Encryption using strong cryptographic technique is a very effective way of making sure that information is accessible to only authorized users. Breaking Authentication In the web application arena, it is extremely important to make sure that information is given to appropriate users. Most of the time mechanism of making this sure is by implementing username/password or some other form of validation, which make sure that requested user in indeed the real user. When a legitimate user transmits this information from browser to server, this information is on the net and potentially available to every hacker to exploit. If this data is not encoded properly, this information can be interpreted, if feature like nonce is not implemented, whole request can be replayed by attacker. Even at the client side, you need to make sure that simple and overly informative messages related to validation failures are not making life easy for attacker and harder for you. You also need to check if there is some restriction on the field length for password, if login name passwords are case sensitive or not and so on. If possible techniques like CAPTCHA (Accompanying simple word recognition in image format, which will be difficult for the computers to identify but easy for humans) can also implemented as a protection against brute force attack. You should also make sure that wherever it make sense, information is sent over HTTPS instead of HTTP. Web Services Last part of this series is devoted to the security testing for web services. In past few years, we have seen tremendous growth in the usage of web services. Before dwelling into the security aspects related to web services, lets discuss very briefly, what is Web Service? Web Services are self describing, self contained modular pieces of functionality that can be published, located, and

invoked across the Internet. Web Services can expose business functionality, data and services over the web using their Interfaces. At the core of web services lie different technologies like extensible Mark-up language (XML), Simple Object Access Protocol (SOAP), Web Service Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI). XML is used to describe the data independent of application, platform, protocol etc. SOAP is used to transport XML in the network, WSDL contains the information related to interface and UDDI allows you to find specific web service you need. WSDL offers many benefits over traditional API's as it provides flexibility, platform independence along with the loosely coupled architecture, Because of its loosely coupled architecture and general availability of its interface, Web services are vulnerable to some more threats along with some of the threats we have already covered in our previous articles. WSDL Scanning Attack Though WSDL is designed to expose and describe all the information that is available in a method, some time information not intended for out side your corporation wall can also become accessible to general public. This might happen because of many reasons. For a seasoned attacker, that might be a wonderful piece of information. Scanning for the publicly available WSDL is also not very difficult. Most of the public facing web services can also be accessed by search engines by specifying appropriate search string, for example in Google you can search for specific file types or presence of some keywords like WSDL in URL. Parameter Tampering As a person responsible for making sure that your web service is safe and secure, you need to make sure that you still do all the validations that you would do otherwise. For example, underlying format for transferring data in web services is XML and it can be assumed that in a valid request data will be well formed and will follow rules specified in XML schema, still you need to validate every data you receive. XML will consider 1=1 or as valid string, but you need to make sure and understand that strings like these can be used to perform attacks on your web application and should be validated before further processing. XPATH Injection XPATH is a language for querying XML document. It is very much similar to SQL in purpose, but instead of querying a database for tables and rows, using XPATH you can query a XML document for specific information by specifying node, node-set etc. An attacker can inject malicious XPATH expression as part of valid SOAP request, which can lead to unauthorized data access as well. While using web services, you should treat XPAT injection very much similar to the SQL injection and rely on validating every data you receive. Recursive and Oversize Payload attack XML uses nesting to represent complex relationship among elements. When an element appears within another element, the inner element is termed as nested. Nesting is typically used to represent real world structures in a better way. However, an attacker can easily nest thousands of

elements or attributes in an attempt to break web service. Since most of the XML based system attempt to load complete document before processing it, nesting or overly big XML document can potentially break the web services. Specially, if your application is using DOM (loading XML into memory before accessing it) , it might be susceptible to this vulnerability. These articles are influenced by the book ( How to Break Web Software from Mike Andrews and James A. Whittaker ) I have recently read and should be a good read for you if you need information on web application security testing.