OWASP Web Testing Methodology
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Meucci, Matteo
The speech goal is to show the OWASP testing methodology and how you can implement a software development lifecycle that permit to develop more secure applications. The Open Web Application Security Project (OWASP) wants to deliver free tools and documentation for the Web Application Security. The talk will present the new OWASP Testing Guide v3 that includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues. OWASP Testing Guide v3 is a 349 page book; we have split the set of active tests in 9 sub-categories for a total of 66 controls to test during the Web Application Testing activity. FOSDEM (Free and Open Source Development European Meeting) is a European event centered around Free and Open Source software development. It is aimed at developers and all interested in the Free and Open Source news in the world. Its goals are to enable developers to meet and to promote the awareness and use of free and open source software.
 Okay, good morning. I'm Matteo Mayucci from HoWasp and thank you FOSDEM for inviting me to speak here. It's my first time here in FOSDEM and I think it's a congratulations for your university because it's very nice and I would like to study here but I study in Italy, in Bologna. So this is the agenda. I would like to introduce you the HoWasp project and the new HoWasp testing guide that is a methodology to test the security of a web application. So I introduce how to test a web application, a short introduction and then I would like to introduce how to improve software security in your software development lifecycle and then question and answers. Okay, two words about me. I founded the HoWasp Italy chapter in 2005 and I lead the testing guide project from two years and in the spare time I work for Mind & Security that is an application security company. So who knows about HoWasp? Great, okay. So HoWasp stands for the Open Web Application Security Project and is a project dedicated to find and fighting the causes of an insecure software. So we have an HoWasp foundation and everyone is a volunteer inside HoWasp. Everyone can participate. So everything we do is free and open source. So maybe it's for reason that we are here now. Okay, so the main object of HoWasp is developing tools, standard and documentation related to web application security. We have a thousand of active members all around the world. We have more than 100 chapters around the world and millions of it on our site. So if we think at HoWasp we have four areas. We have an area called education in which we develop the first tool for the education of people on web application security. For example, the Overstop 10 tell you about the ten vulnerability of the web application. So for example, from cross-site scripting, SQL injection and so on, tell you what are these vulnerabilities and how you can protect about it. Then we do training. We do conferences. So the next conference is in Poland with confidence. And we develop web got that is an application that is vulnerable to web applications security so you can test on your own the vulnerability. And this software also, the other is free available on www.howasp.org. Then we have a community. We have a lot of chapters and we have a lot of projects incubator. And we have a wiki portal so everyone can edit the contents of the wiki portal. Then we have a building area and we have the HoWasp building guide that is a guide that tells you how to develop SQL software. There is a code review guide that tells you how to review the code for the security. Then there is there are other projects like Horizon that is a tool that do a static analysis of the code. And then for the verification area, we have the testing guide that is the core of the presentation. And we have a web scarab that is a tool is an HTTP proxy that runs on your local machine and can intercept all the HTTP requests from the client to the server. So you can see all the requests and edit it and see how the server can respond. So web scarab and the testing guide are together the framework for the testing. The testing guide is a methodology and the web scarab is a tool for the tester. Then we do validation and certification but there are new items. So the testing guide is free and open. We use the creative commons so everything is open and free. You can download everything we do. It's just a puzzle of the piece. It's just a piece of a puzzle so you can see there are a lot of tools. There is the building guide, the code review guide and the testing guide. Here they are all as community. We have a lot of chapters all around the world in which we can debate the web application security and we organize conferences locally, et cetera. Now the total projects in OWASP are 88. 42 related to tools and 32 related to the documentation and nine for technology and five for the activities inside the OWASP foundation. So all these projects are sponsored by the OWASP foundation because we collect money from the conferences and maybe from the conferences. So OWASP now give some money to the leader that developed the documentation or tool. Now the goal is to improve the quality of our projects. So now all the projects are labeled alpha, beta or release. For example, the OWASP is a release project. So now our goal is to increase the quality and create professional OWASP books. So you can download from the site, the PDF, for example, of the testing guide or you can buy from the book that is at the price of the printing. So it's less than $10, something like that. Okay. So this is, now we will talk about the testing guide. Just a little history. The testing guide starts from January 2004 from Daniel Kappler that delivered the first testing guide that was 20 pages in which he collects all the tests to do on the application. Then in July the 40th we developed the version 1.1. In December 2006 we decided to develop a new project that is version 2. It is more and more bigger than the other version. Now in last December we developed the version 3. You can see from here that the complexity of the project. From the beginning we released a document of 10, 20 pages. Then 30, then more than 250 and now we are nearly 350. So the complexity of the articles and the methodology is growing, it's growing. What are the goals of the OWASP testing? We would like to create a complete new project focused on web application penetration testing. The goal is to, we don't like to see the security as a black heart. So we would like to share with the tester and with the auditor and with the other that are involved in the audit of the application a common methodology. So the question is here to develop a methodology that is completely open. Here the action plan. The last version, so the version 2 takes about 3-4 months to the develop and we begin with brainstorming to understand which is the methodology. So we collect all the web application penetration testing experts and we decide together to develop a common methodology. So the first stage is very complex because we have to collect all the ideas of the other and create the methodology because we don't like to, we didn't want to create the my methodology on your methodology but the community methodology. So it's not so easy. Then when we decide the index and the templates we write down the articles on the wiki model and we review the articles, review all the guides and then we write the Tindoc format and PDF and then we release the candidate and so on. The testing guide version 3 started on April 2008 and firstly we do an hours leader brainstorming about how to improve the version 2 and we do a call for participation. We had 21 authors and in the version 2 we had nearly 50 authors so the authors are less. Then we describe, we discuss all the articles and here you can see that there is an action plan about this guide. So here is the book that you can download from the site and the PDF. You can see there is introduction, etc. And chapter 4 is the core of the book in which we describe the web application penetration testing methodology and then we focus on how to write the reports. When you find all the vulnerabilities on the web application we decide also to write a methodology to describe how to write a report, how to collect the vulnerability, how to value the risk associated with each vulnerability, etc. Because it's fundamental to present the result in the right manner. Then we have four appendix. We describe all the testing tools that we use. Web Scalab is the key tool but there are a lot of other tools. For example for SQL injection we have SQL Ninjas, SQL map and so on. Then the reading, the FUDZIN vector and then code and injection. Now we go to see it better. The difference from the version 2 and the version 3 and the version 2 we had eight subcategories and now we have ten subcategories. We create the configuration management testing and the authorization testing and the encoded appendix. So here I would like to show the index. We describe the robust testing framework and so on. Here you can see that we start from the information gathering that is the first category of the test and is the passive test. It's not an active test. In the information gathering we collect all the information about the application. So we understand all the entry points. Where is the application because maybe the target is only an IP address. So we have to understand where is the application in which part is running and so on. Then we do configuration management testing. For example we go to see the strength of the SSL protocol implemented. We go to implement the infrastructure configuration management testing and so on. And then we go for the authentication testing. Here we are, we were split in ten controls to perform. The first one is to perform the credential transport over an encrypted channel. For example if the, when you have a username and password to verify if the username and password information goes over an encrypted channel. And then we go for testing for user enumeration. For example if you know a valid user and if you try a not valid user with the wrong password maybe the application responding in a different manner. So you can understand that the user is available on the application and you can enumerate a lot of user. Then we can do the default attack. Okay. Just a flash here. In the second part I will show some examples. So I go a little bit fast. Then we do the session management testing. You know that web application running on over HTTP. And HTTP protocol is a stateless protocol. So you have to implement your own state or you use the framework for example from J2E or.NET there is a session management mechanism. So here we test the strengths of this mechanism of the session management. Then we do authorization testing. When a user is authenticated on my application I have to test if the user can do something that is not authorized for. Maybe he can read PDF that is private or he can do some action that is valid only from the administration and so on. Then we do data validation testing. Data validation testing is the big one. Maybe I didn't find an application that suffers from data validation vulnerabilities. It's quite impossible because here we test all the entry points of the application and we understand how the application validates this information before doing a particular action. For example, create a SQL query on the database or create an output on the browser. So if the validation is not correct we can perform across scripting or SQL injection and so on. So here we describe also for the SQL injection how to test the Oracle, how to test my SQL server and so on. Here are all the other data validation testing. Then we describe the Daniel service testing. Usually we didn't perform the Daniel service testing because we touched the application and not in the environment. The application is running so it's not very important to understand if software of Daniel service. Then when we are a web service we test also the web services. So here we describe how to test web services and if we have an agile application we describe how to test the hedgehogs. And then chapter five describe how to write reports and evaluate the real risk. So here is the index of the methodology. So what is a web application penetration testing? It's a process. It's a process that involves an active analysis of the application to find the weakness and the vulnerabilities. It's a black box process. So we don't know the source code of the application. We know only the URL on the IP address where the application is running. So this approach is a black box approach. For example the code review testing is a white box approach. That means that you know everything about the code. So you can read the code, understand when a call is function is called, etc. You can understand everything about the code. Here we don't know nothing. So the methodology described here with the tool is together a web application testing. Our approach in writing the guide is open and collaborative. So you know everything can give is contribution and collaborative because we decide together what to write and it's not a community methodology. Then we would like to create a testing methodology that was consistent and repeatable under the time. So if I test an application with this methodology we would like to have the same results from another tester. And yeah, the quality is another target. Here for example a testing paragraph template. Initially we describe we have a brief summary of what we want to test. We describe the issue and we describe from a black box testing example and gray box testing example and then we collect all the references and the tool that are useful for this kind of test. For example, here is one of the paragraph about the cross-site scripting and here we describe what is a cross-site scripting inside the brief summary. We describe the issue. So how you can test for the cross-site scripting and here black box testing the methodology. So you have to detect the input vector and to inject some script to understand how the application reflect your information on your browser. And for example here is an example where for example you have the URL where user equal Mr. Smith and Mr. Smith is reflected on the browser. So for example you can write down script alert 123 slash script instead Mr. Smith and if you collect this kind of screenshot you understand that the application doesn't correct validate the output. So you can create a reflected cross-site scripting. Okay. Here are other example and here are references. So you can read the white paper and the tools. Here again the web scallop and all was called 9000 is another free tool that is a collection of web applications for the cross-site scripting. So you can use it. Et cetera. Okay. Okay. Here difference because we describe also the gray box testing. For example if we know the session ID generation algorithm we know something about the application. So it's something of gray box testing. Okay. But again the white box testing is not the target of this guide but the code review guide that is another guide of OWASP is focused on the white box testing. So now I introduce the methodology with some examples. We start, I say that we start from the information gathering. So the first phase in the security assessment is to play with the application with a tool like web scallop or idle tool and understand how the application answered to you and to find all the three of the applications. So all the directory accessible from the public etc. So you can write down all the entry points of the application. Entry points, I mean the entry points for example when there is a form on the web page, when you insert user name and password, user name and password are two entry points of the application and these are something that you have to test for example for data validation. So you can understand how the application is functioning during the information gathering and then you use a spider and robots and crawlers to understand everything about the application. And then once you identify the application entry points we do web application fingerprinting to understand which are the web server, the application server running on the application. And then we do application discovery and analysis of error codes that are interesting for example when you try to request something particular and the application respond with for example Microsoft DB all error you understand that there is some kind of database at the back end and maybe you can collect information about the name of the table and you can write down for the test for the SQL injection. So here you collect many, many information about the your application. Here for example if you perform an HTTP head request from your target the answer is something like that and here for example you can understand that there is a page version 1.3.3 and there is a unique server and there is a redact etc. But for example what if I do the same request and the header of the server is obfuscated. For example here you can see the third line obfuscated and obfuscated etc. Also we can understand that which is the server because the header is in a different manner. So for example a page 1.3.2.3 answers with date as fair field in the header and so on. So you can understand which are the platform. Then we do configuration management testing. So for example the SSL strength of the application we do DB list testing infrastructure configuration management. For example we do also the old backup and reference files that we find quite a lot on the application. For example if the login is login.JSP if you try to request login.back or login.hold maybe you can find this information and maybe there are some information confidential inside this reference file. So you can once again find useful information for the test. Then we test for example for HTTP methods. For example if put or delete is admitted on your web application and maybe you can do other kind of test. Here for example we can find an access to Tomcat interface from the internet maybe. Or here from Nestus we can extract all the ciphers that the server admit. Here for example you can see that there is a desk and MD5 cryptography algorithm and hashing algorithm that are quite old and it's not it's better don't use it. Then we test the session management. Session management is a critical part of security test because the HTTP is stateless and so you have to understand how the application implement the state of the user that is authenticated on the application. So we test for the session management schemes for the Q key attributes. For example if when I authenticate on an application I understand if I go to see if when the directive set Q key I go to see if the Q key is secure is HTTP only if there is a date of in which is valid or not and these are all attributes that you have to put on your Q key. Then we test for session fixation for exposed variable and cross-circuit forgery. Now we see some example. Here for example on the right we have a web application and on the left there is a user that hold this username and password. Here I post my username and password via HTTPS on the application and on the bottom you can see the parameter username and password. Then the web application verify the credential and if it's okay the web application will generate a Q key and says welcome to Mario Rossi and if you look at the header of the answer of the web application you can see something like that a set Q key authentication equals something a string of characters that will be set on the browser of the user. So for example if I request many many cookies of the application and for example using web scarab you can collect a lot of cookies 100 1000 of the application so you can understand how the application generate the cookie. Maybe the application generate the same cookie every time we don't find it but or there is a linearity in the generation. Here for example is a simple very simple example you can understand that if I collect a lot of cookie I can understand that there is a linearity in the generation so I can understand that the next cookie is that one just plus two. So for example if I am authenticated on the web application and I request my money how much money I have inside the bank if I understand the mechanism of the session I can modify that with the web scarab so here I send to the web application not my cookies not my ticket the ticket that I understand that is from another person I don't know which person is but I know that maybe there is an open session so I can do a session ejecting. So the web application now verify my identity not from my username password but from the ticket and the ticket is related to Mario Verdi not Mario Rossi. So Mario Rossi can see the account of Mario Verdi this is an example of session ejecting. Okay another example here for example and a web application where you can create your own MMS and then send it to a user via a network mobile phone. Yeah I don't describe everything but the attacker is the first one on the left and there is a laptop and a mobile phone and there is a spoofed identity with another phone and there is a receiver with another phone. Here we can see that there is a stupid error a stupid logic error in which when I call the server the servlet for the payment here you can see that I send a cookie that there is inside my MSISDN so my telephone number. So I send him a session ID and my telephone number what if I modify that number with another number and we saw that the application doesn't correct validate the session ID but validate only the MSISDN so the result is that the application charges another user and not me so I can send the spoofed MMS to another person and pay a spoofed identity. Another test very interesting is a cross-site request forgery that is quite new vulnerability that is not so we found a lot of cross-site request forgery and I don't find the okay I describe the test we find the cross-site request forgery when the application permits to send an authorized function without authorizer every time the user and we use the image tag attack to create and enforce the user to commit that action now we see better. The first step is to find a vulnerability function for example if an application has a function to create a new user or there is a and this is only for the admin for example or there is a found transfer for example of all the online banking site permit you to create a found transfer we understand that there are these functions then we analyze how I send this information to the server for example when I click submit I want to create a transfer found from my found to another found with 1000 euro of a fund I understand which is the request so I can create a malicious email or malicious site in which I force the browser of another user to do that action. The result is not an authorized action executed but the user don't understand that. Another example so for example online banking here is the transfer found mechanism you can see the HTTP's example bank.com the transfer function in which is the variable are EU and 2 this is very very simple to understand the vulnerability for example if I am authenticated and create a transfer to the count 1234 and this is the amount the request is something like that. The second step is that the user must be authenticated on the application the user which is subject to the attack must be authenticated on the application and then I force him to request these HTTP requests using the image tag. Here is the example if I create a page like that in which inside DHTML I insert the exact request that I understand that the application user for a transfer money I can force a user to request this one. So for example if I send an email to one million user and maybe one user is reading this email consequently if he is authenticated on the web application the browser will execute this command. So the user don't understand that he is doing that and the application sees that the correct user is doing that so it's a big problem for say I didn't do that but the application sees that you are authenticated and you are performing detection so it's a big problem to understand that you are not requested this kind of transfer fund. So the cross request forger is a big vulnerability to test and to understand. Then authentication testing if you have questions please because I see. Authentication testing we go to see how the authentication mechanism is robust and so on. So we test the credential, we test for user numeration, for user account, for the brute force of the web application by passing the authentication schema. Here we can see some example for example. Here there is an application with Mutual Digital Certification certificate and you can see the user with his own public key certificate and the application install a public key certificate on the proxy behind the application. So here we found for example that the handshake SSL and Mutual authentication is from the user, browser and the proxy. So on the layer beside the application layer and then we analyze that there is a script client that collect the information of the user certificate. So there is something inside the browser that go to see the user certificate and send the user distinguished name to the web application. So here you can see that there is an error, a logic error because here is the authentication post. When I send from my browser to the server my user distinguished name you can see in the last row user distinguished name equal 100. So I do handshake SSL with the proxy but from an application layer point of view the client send to the application is distinguished name and this is a bigger error because the application verify with SSL who is the user and the application must see inside the certificate of the user once that the certificate is verified who is the user but not asking to the user which user are you. So here there is a big problem because everyone here think that the application is very secure because I give to every user a digital certificate so I think that I implement a very secure authentication mechanism but if you go inside and understand all the request that the application is doing with the browser you can understand that there is a big security flow. Then we do authorization testing. We test for path traversal for bypassing authorization schema and testing for privilege escalation. For example here you can see a site where you can download something from the five system of the server and what if you do something like that. The ID parameter here is validated or you can insert everything and maybe navigate inside the five system of the web application. For example you can see the HG pass VUDD so all the running process etc. Here you can see how to bypass the authorization schema. So for example there is an ad user JSP is part of an administrative menu. You can see that an admin can create a new fake user with role 3 and group 001 and you have to test if another user that has not the privilege of an admin can do the same. For example if you understand that there are some administrative function this test want to verify if I do the same with no privileges what is the answer of the application. The application is currently validating the authorization mechanism or not. If you test it maybe you can find a lot of surprise. Another test is testing for privilege escalation. For example here the server response after the user authentication. Here the application uses an ID field with the profile value you can see if 1 and this value is the authorization parameter and once again is given on the client that you know everything that is on the client is available so you have to verify that before using this information. What if the user modified the value from 16th 1 to 16th 3 and in this case we understand that we begin we become administrator of the application. So once again the authorization must be on the server side not on the client side. Then we perform a business logic testing that is a test where we understand for example if there is a workflow inside the application and to execute a particular function I have to go throughout step 1, step 2 and step 3. What if from step 1 go directly to step 3? There is some mechanism inside the application that verify that I have to do the step 2. Then we go for data validation testing. Here as I say there are the main vulnerability inside the application because the application are full of entry points and it is very difficult to verify all the entry points and validate correctly the output, the SQL query, the held up query and so on. So here for example is a reflected cross-excripting where in this site there is a search field at the bottom and what if I write something like that instead of home, I research for home or something like that. Maybe I can insert a script and if the output is something like that I understand that the application does not validate the output. The stored cross-excripting here for example we have a chat where you can see when you can insert a title and message what if the application permit to write an HTML and then you post something like that and then when a user click on test cross-excripting we will execute on the browser the script. So for example I can store the, I can steal the cookie of the user or I can manipulate all the browser of the user. Okay, command injection. Here an example from where I got. What if there is something like that in which I request a file on the file system and simply add something like that. The result here is something like that. You access to the file but you can access also to the volume of the hard disk. Then we do web services testing. There is a plugin inside web scarab that is very useful for the view WSDL. So when you find the service you can use this plugin and you can insert maybe you can see here something inside the web service and understand how the web service can answer to your request. Here are some XML structural text. For example if I invert the tag of the XML request. Here if I insert a large payload of the inside the XML what is the answer of the service. Then I will shortly introduce you the web application testing. Then it's important to have a testing report model. So we create a always pretty scripting model. It's very easy. Risk is equal likelihood for the impact. We need to identify a risk, get information about the vulnerability, the trade agent and then understand the impact of the successful exploit on the business. So we can understand what to fix, what are the risk models, etc. So here you can see the writing report that we can suggest is something like that. In exactly summary a technical management overview and assessment findings and a table where for each category of tests you can see all the vulnerabilities, the name of the vulnerabilities and where is the effect item, where are the findings and the solution and the evaluated risk about the vulnerability. Okay so how can you improve software development lifecycle? The OBAs guidelines can help you to develop web application in a more secure manner. The building guide tells you how to develop the web application to protect for SQL injection for example. The code review guide tells you from a white box test point of view how to test the function that you are implementing. So viewing the code understand that there are security risks. And the testing guide tells you how to perform SQL injection once that you have developed the web application and you don't know nothing about your web application. So inside the software development lifecycle we can divide in five phases from the defined design, the deploy and maintenance phase. The controls to implement are training on the user to do policy review guidelines, adopt guidelines, doing code review and doing web application penetration testing. So here is a big picture about the SDLC and OBAs guidelines. On the left you can see that before the SDLC is improved the OBAs guidelines can give you an help on how you can create your development lifecycle. And then in the defined and design phases you can use the building guide to develop a secure software and in the development phase you can use the code review guide and before the deploy using the testing guide that just described. SDLC is not a buy two bucks to buy because you know it's a very complex process. And okay, just a flash about the PCI standard and the OBAs. You can see that the control 6.5, the PCI standard tell you to use the OBA standard inside your application that you are collecting information about credit card number and so on. So this guide is useful. We think that this guide is useful for the industry, for the pen testers, so the company that do audit of the application and for the clients. So we have a methodology that is open and shared between the client and the the audit. Future steps. In OBAs we would like to integrate better the develop the code review and the testing guide and improve the client side security. And okay. So I thanks all the authors of the version 3 of the testing guide and we have one minute for the answer, for the question and answer. Inside an organization. Yeah. We saw that many companies require web application penetration test. So the black box approach. But we know that it's the last step that we will have to do. So our idea is to begin to implement the control in the first phase of the software development cycle. So from the guidelines and the code review. So we know that doing code review is more effective than doing web application penetration testing. So your answer is correct. The code review is better. It's better because you can see the code. You can see everything about the code and see okay in this line, in this component you have a problem. And you can write down the remediation immediately. And instead if you do a black box code, a black box assessment, you know that there is a vulnerability but maybe you don't know where inside your software. And it's more complicated and it's in other phase of the development. So more cost and it's okay. Other questions? Thank you very much.
 Okay, good morning. I'm Matteo Mayucci from HoWasp and thank you FOSDEM for inviting me  to speak here. It's my first time here in FOSDEM and I think it's a congratulations for your  university because it's very nice and I would like to study here but I study in Italy, in  Bologna. So this is the agenda. I would like to introduce you the HoWasp project and the new  HoWasp testing guide that is a methodology to test the security of a web application. So I  introduce how to test a web application, a short introduction and then I would like to  introduce how to improve software security in your software development lifecycle and then  question and answers. Okay, two words about me. I founded the HoWasp Italy chapter in 2005 and I  lead the testing guide project from two years and in the spare time I work for Mind & Security  that is an application security company. So who knows about HoWasp? Great, okay. So HoWasp stands  for the Open Web Application Security Project and is a project dedicated to find and fighting  the causes of an insecure software. So we have an HoWasp foundation and everyone is a volunteer  inside HoWasp. Everyone can participate. So everything we do is free and open source. So maybe  it's for reason that we are here now. Okay, so the main object of HoWasp is developing tools,  standard and documentation related to web application security. We have a thousand of  active members all around the world. We have more than 100 chapters around the world and millions  of it on our site. So if we think at HoWasp we have four areas. We have an area called education in  which we develop the first tool for the education of people on web application security. For example,  the Overstop 10 tell you about the ten vulnerability of the web application. So for example, from  cross-site scripting, SQL injection and so on, tell you what are these vulnerabilities and how you  can protect about it. Then we do training. We do conferences. So the next conference is in Poland  with confidence. And we develop web got that is an application that is vulnerable to web  applications security so you can test on your own the vulnerability. And this software also,  the other is free available on www.howasp.org. Then we have a community. We have a lot of  chapters and we have a lot of projects incubator. And we have a wiki portal so everyone can edit  the contents of the wiki portal. Then we have a building area and we have the HoWasp building guide  that is a guide that tells you how to develop SQL software. There is a code review guide that  tells you how to review the code for the security. Then there is there are other projects like  Horizon that is a tool that do a static analysis of the code. And then for the verification area,  we have the testing guide that is the core of the presentation. And we have a web scarab that is a  tool is an HTTP proxy that runs on your local machine and can intercept all the HTTP requests  from the client to the server. So you can see all the requests and edit it and see how the server  can respond. So web scarab and the testing guide are together the framework for the testing. The  testing guide is a methodology and the web scarab is a tool for the tester. Then we do validation  and certification but there are new items. So the testing guide is free and open. We use the  creative commons so everything is open and free. You can download everything we do. It's just a  puzzle of the piece. It's just a piece of a puzzle so you can see there are a lot of tools. There  is the building guide, the code review guide and the testing guide. Here they are all as community.  We have a lot of chapters all around the world in which we can debate the web application security  and we organize conferences locally, et cetera. Now the total projects in OWASP are 88. 42  related to tools and 32 related to the documentation and nine for technology and five for the  activities inside the OWASP foundation. So all these projects are sponsored by the OWASP  foundation because we collect money from the conferences and maybe from the conferences. So  OWASP now give some money to the leader that developed the documentation or tool. Now the  goal is to improve the quality of our projects. So now all the projects are labeled alpha, beta  or release. For example, the OWASP is a release project. So now our goal is to increase the  quality and create professional OWASP books. So you can download from the site, the PDF,  for example, of the testing guide or you can buy from the book that is at the price of the  printing. So it's less than $10, something like that. Okay. So this is, now we will talk  about the testing guide. Just a little history. The testing guide starts from January 2004  from Daniel Kappler that delivered the first testing guide that was 20 pages in which he  collects all the tests to do on the application. Then in July the 40th we developed the version  1.1. In December 2006 we decided to develop a new project that is version 2. It is more  and more bigger than the other version. Now in last December we developed the version  3. You can see from here that the complexity of the project. From the beginning we released  a document of 10, 20 pages. Then 30, then more than 250 and now we are nearly 350. So  the complexity of the articles and the methodology is growing, it's growing. What are the goals  of the OWASP testing? We would like to create a complete new project focused on web application  penetration testing. The goal is to, we don't like to see the security as a black heart.  So we would like to share with the tester and with the auditor and with the other that  are involved in the audit of the application a common methodology. So the question is here  to develop a methodology that is completely open. Here the action plan. The last version,  so the version 2 takes about 3-4 months to the develop and we begin with brainstorming  to understand which is the methodology. So we collect all the web application penetration  testing experts and we decide together to develop a common methodology. So the first  stage is very complex because we have to collect all the ideas of the other and create the  methodology because we don't like to, we didn't want to create the my methodology on your methodology  but the community methodology. So it's not so easy. Then when we decide the index and  the templates we write down the articles on the wiki model and we review the articles,  review all the guides and then we write the Tindoc format and PDF and then we release  the candidate and so on. The testing guide version 3 started on April 2008 and firstly  we do an hours leader brainstorming about how to improve the version 2 and we do a call  for participation. We had 21 authors and in the version 2 we had nearly 50 authors so  the authors are less. Then we describe, we discuss all the articles and here you can  see that there is an action plan about this guide. So here is the book that you can download  from the site and the PDF. You can see there is introduction, etc. And chapter 4 is the  core of the book in which we describe the web application penetration testing methodology  and then we focus on how to write the reports. When you find all the vulnerabilities on the  web application we decide also to write a methodology to describe how to write a report,  how to collect the vulnerability, how to value the risk associated with each vulnerability,  etc. Because it's fundamental to present the result in the right manner. Then we have  four appendix. We describe all the testing tools that we use. Web Scalab is the key tool  but there are a lot of other tools. For example for SQL injection we have SQL Ninjas, SQL  map and so on. Then the reading, the FUDZIN vector and then code and injection. Now we  go to see it better. The difference from the version 2 and the version 3 and the version  2 we had eight subcategories and now we have ten subcategories. We create the configuration  management testing and the authorization testing and the encoded appendix. So here I would  like to show the index. We describe the robust testing framework and so on. Here you can see  that we start from the information gathering that is the first category of the test and  is the passive test. It's not an active test. In the information gathering we collect all  the information about the application. So we understand all the entry points. Where is  the application because maybe the target is only an IP address. So we have to understand  where is the application in which part is running and so on. Then we do configuration  management testing. For example we go to see the strength of the SSL protocol implemented.  We go to implement the infrastructure configuration management testing and so on. And then we  go for the authentication testing. Here we are, we were split in ten controls to perform.  The first one is to perform the credential transport over an encrypted channel. For example  if the, when you have a username and password to verify if the username and password information  goes over an encrypted channel. And then we go for testing for user enumeration. For example  if you know a valid user and if you try a not valid user with the wrong password maybe  the application responding in a different manner. So you can understand that the user  is available on the application and you can enumerate a lot of user. Then we can do the  default attack. Okay. Just a flash here. In the second part I will show some examples.  So I go a little bit fast. Then we do the session management testing. You know that  web application running on over HTTP. And HTTP protocol is a stateless protocol. So  you have to implement your own state or you use the framework for example from J2E or .NET there is a session management mechanism. So here we test the strengths of this mechanism  of the session management. Then we do authorization testing. When a user is authenticated on my  application I have to test if the user can do something that is not authorized for. Maybe  he can read PDF that is private or he can do some action that is valid only from the  administration and so on. Then we do data validation testing. Data validation testing  is the big one. Maybe I didn't find an application that suffers from data validation vulnerabilities.  It's quite impossible because here we test all the entry points of the application and  we understand how the application validates this information before doing a particular  action. For example, create a SQL query on the database or create an output on the browser.  So if the validation is not correct we can perform across scripting or SQL injection  and so on. So here we describe also for the SQL injection how to test the Oracle, how  to test my SQL server and so on. Here are all the other data validation testing. Then  we describe the Daniel service testing. Usually we didn't perform the Daniel service testing  because we touched the application and not in the environment. The application is running  so it's not very important to understand if software of Daniel service. Then when we  are a web service we test also the web services. So here we describe how to test web services  and if we have an agile application we describe how to test the hedgehogs. And then chapter  five describe how to write reports and evaluate the real risk. So here is the index of the  methodology. So what is a web application penetration testing? It's a process. It's  a process that involves an active analysis of the application to find the weakness and  the vulnerabilities. It's a black box process. So we don't know the source code of the application.  We know only the URL on the IP address where the application is running. So this approach  is a black box approach. For example the code review testing is a white box approach. That  means that you know everything about the code. So you can read the code, understand when  a call is function is called, etc. You can understand everything about the code. Here  we don't know nothing. So the methodology described here with the tool is together a  web application testing. Our approach in writing the guide is open and collaborative. So you  know everything can give is contribution and collaborative because we decide together  what to write and it's not a community methodology. Then we would like to create a testing methodology  that was consistent and repeatable under the time. So if I test an application with this  methodology we would like to have the same results from another tester. And yeah, the  quality is another target. Here for example a testing paragraph template. Initially we  describe we have a brief summary of what we want to test. We describe the issue and we  describe from a black box testing example and gray box testing example and then we collect  all the references and the tool that are useful for this kind of test. For example, here is  one of the paragraph about the cross-site scripting and here we describe what is a cross-site  scripting inside the brief summary. We describe the issue. So how you can test for the cross-site  scripting and here black box testing the methodology. So you have to detect the input vector and  to inject some script to understand how the application reflect your information on your  browser. And for example here is an example where for example you have the URL where user  equal Mr. Smith and Mr. Smith is reflected on the browser. So for example you can write  down script alert 123 slash script instead Mr. Smith and if you collect this kind of  screenshot you understand that the application doesn't correct validate the output. So you  can create a reflected cross-site scripting. Okay. Here are other example and here are  references. So you can read the white paper and the tools. Here again the web scallop  and all was called 9000 is another free tool that is a collection of web applications  for the cross-site scripting. So you can use it. Et cetera. Okay. Okay. Here difference  because we describe also the gray box testing. For example if we know the session ID generation  algorithm we know something about the application. So it's something of gray box testing. Okay.  But again the white box testing is not the target of this guide but the code review guide  that is another guide of OWASP is focused on the white box testing. So now I introduce  the methodology with some examples. We start, I say that we start from the information gathering.  So the first phase in the security assessment is to play with the application with a tool  like web scallop or idle tool and understand how the application answered to you and to  find all the three of the applications. So all the directory accessible from the public  etc. So you can write down all the entry points of the application. Entry points, I mean the  entry points for example when there is a form on the web page, when you insert user name  and password, user name and password are two entry points of the application and these  are something that you have to test for example for data validation. So you can understand  how the application is functioning during the information gathering and then you use  a spider and robots and crawlers to understand everything about the application. And then  once you identify the application entry points we do web application fingerprinting to understand  which are the web server, the application server running on the application. And then  we do application discovery and analysis of error codes that are interesting for example  when you try to request something particular and the application respond with for example  Microsoft DB all error you understand that there is some kind of database at the back  end and maybe you can collect information about the name of the table and you can write  down for the test for the SQL injection. So here you collect many, many information about  the your application. Here for example if you perform an HTTP head request from your  target the answer is something like that and here for example you can understand that there  is a page version 1.3.3 and there is a unique server and there is a redact etc. But for  example what if I do the same request and the header of the server is obfuscated. For  example here you can see the third line obfuscated and obfuscated etc. Also we can understand  that which is the server because the header is in a different manner. So for example a  page 1.3.2.3 answers with date as fair field in the header and so on. So you can understand  which are the platform. Then we do configuration management testing. So for example the SSL  strength of the application we do DB list testing infrastructure configuration management.  For example we do also the old backup and reference files that we find quite a lot on  the application. For example if the login is login.JSP if you try to request login.back  or login.hold maybe you can find this information and maybe there are some information confidential  inside this reference file. So you can once again find useful information for the test.  Then we test for example for HTTP methods. For example if put or delete is admitted on  your web application and maybe you can do other kind of test. Here for example we can  find an access to Tomcat interface from the internet maybe. Or here from Nestus we can  extract all the ciphers that the server admit. Here for example you can see that there is  a desk and MD5 cryptography algorithm and hashing algorithm that are quite old and it's  not it's better don't use it. Then we test the session management. Session management  is a critical part of security test because the HTTP is stateless and so you have to  understand how the application implement the state of the user that is authenticated on  the application. So we test for the session management schemes for the Q key attributes.  For example if when I authenticate on an application I understand if I go to see if when the directive  set Q key I go to see if the Q key is secure is HTTP only if there is a date of in which  is valid or not and these are all attributes that you have to put on your Q key. Then we  test for session fixation for exposed variable and cross-circuit forgery. Now we see some  example. Here for example on the right we have a web application and on the left there  is a user that hold this username and password. Here I post my username and password via HTTPS  on the application and on the bottom you can see the parameter username and password. Then  the web application verify the credential and if it's okay the web application will generate  a Q key and says welcome to Mario Rossi and if you look at the header of the answer of  the web application you can see something like that a set Q key authentication equals  something a string of characters that will be set on the browser of the user. So for  example if I request many many cookies of the application and for example using web  scarab you can collect a lot of cookies 100 1000 of the application so you can understand  how the application generate the cookie. Maybe the application generate the same cookie every  time we don't find it but or there is a linearity in the generation. Here for example is a simple  very simple example you can understand that if I collect a lot of cookie I can understand  that there is a linearity in the generation so I can understand that the next cookie is  that one just plus two. So for example if I am authenticated on the web application and  I request my money how much money I have inside the bank if I understand the mechanism of  the session I can modify that with the web scarab so here I send to the web application  not my cookies not my ticket the ticket that I understand that is from another person I  don't know which person is but I know that maybe there is an open session so I can do  a session ejecting. So the web application now verify my identity not from my username  password but from the ticket and the ticket is related to Mario Verdi not Mario Rossi.  So Mario Rossi can see the account of Mario Verdi this is an example of session ejecting.  Okay another example here for example and a web application where you can create your  own MMS and then send it to a user via a network mobile phone. Yeah I don't describe everything  but the attacker is the first one on the left and there is a laptop and a mobile phone and  there is a spoofed identity with another phone and there is a receiver with another phone.  Here we can see that there is a stupid error a stupid logic error in which when I call  the server the servlet for the payment here you can see that I send a cookie that there  is inside my MSISDN so my telephone number. So I send him a session ID and my telephone  number what if I modify that number with another number and we saw that the application doesn't  correct validate the session ID but validate only the MSISDN so the result is that the  application charges another user and not me so I can send the spoofed MMS to another  person and pay a spoofed identity. Another test very interesting is a cross-site request  forgery that is quite new vulnerability that is not so we found a lot of cross-site request  forgery and I don't find the okay I describe the test we find the cross-site request forgery  when the application permits to send an authorized function without authorizer every time the  user and we use the image tag attack to create and enforce the user to commit that action  now we see better. The first step is to find a vulnerability function for example if an  application has a function to create a new user or there is a and this is only for the  admin for example or there is a found transfer for example of all the online banking site  permit you to create a found transfer we understand that there are these functions then we analyze  how I send this information to the server for example when I click submit I want to create  a transfer found from my found to another found with 1000 euro of a fund I understand  which is the request so I can create a malicious email or malicious site in which I force the  browser of another user to do that action. The result is not an authorized action executed  but the user don't understand that. Another example so for example online banking here  is the transfer found mechanism you can see the HTTP's example bank.com the transfer function  in which is the variable are EU and 2 this is very very simple to understand the vulnerability  for example if I am authenticated and create a transfer to the count 1234 and this is the  amount the request is something like that. The second step is that the user must be authenticated  on the application the user which is subject to the attack must be authenticated on the  application and then I force him to request these HTTP requests using the image tag.  Here is the example if I create a page like that in which inside DHTML I insert the exact  request that I understand that the application user for a transfer money I can force a user  to request this one. So for example if I send an email to one million user and maybe one  user is reading this email consequently if he is authenticated on the web application  the browser will execute this command. So the user don't understand that he is doing  that and the application sees that the correct user is doing that so it's a big problem for  say I didn't do that but the application sees that you are authenticated and you are performing  detection so it's a big problem to understand that you are not requested this kind of transfer  fund. So the cross request forger is a big vulnerability to test and to understand. Then  authentication testing if you have questions please because I see. Authentication testing  we go to see how the authentication mechanism is robust and so on. So we test the credential,  we test for user numeration, for user account, for the brute force of the web application  by passing the authentication schema. Here we can see some example for example. Here there  is an application with Mutual Digital Certification certificate and you can see the user with  his own public key certificate and the application install a public key certificate on the proxy  behind the application. So here we found for example that the handshake SSL and Mutual  authentication is from the user, browser and the proxy. So on the layer beside the application  layer and then we analyze that there is a script client that collect the information  of the user certificate. So there is something inside the browser that go to see the user  certificate and send the user distinguished name to the web application. So here you  can see that there is an error, a logic error because here is the authentication post. When  I send from my browser to the server my user distinguished name you can see in the last  row user distinguished name equal 100. So I do handshake SSL with the proxy but from  an application layer point of view the client send to the application is distinguished name  and this is a bigger error because the application verify with SSL who is the user and the application  must see inside the certificate of the user once that the certificate is verified who  is the user but not asking to the user which user are you. So here there is a big problem  because everyone here think that the application is very secure because I give to every user  a digital certificate so I think that I implement a very secure authentication mechanism but  if you go inside and understand all the request that the application is doing with the browser  you can understand that there is a big security flow. Then we do authorization testing. We  test for path traversal for bypassing authorization schema and testing for privilege escalation.  For example here you can see a site where you can download something from the five system  of the server and what if you do something like that. The ID parameter here is validated  or you can insert everything and maybe navigate inside the five system of the web application.  For example you can see the HG pass VUDD so all the running process etc. Here you can  see how to bypass the authorization schema. So for example there is an ad user JSP is  part of an administrative menu. You can see that an admin can create a new fake user with  role 3 and group 001 and you have to test if another user that has not the privilege  of an admin can do the same. For example if you understand that there are some administrative  function this test want to verify if I do the same with no privileges what is the answer  of the application. The application is currently validating the authorization mechanism or not.  If you test it maybe you can find a lot of surprise. Another test is testing for privilege  escalation. For example here the server response after the user authentication. Here the application  uses an ID field with the profile value you can see if 1 and this value is the authorization  parameter and once again is given on the client that you know everything that is on the client  is available so you have to verify that before using this information. What if the user  modified the value from 16th 1 to 16th 3 and in this case we understand that we begin  we become administrator of the application. So once again the authorization must be on  the server side not on the client side. Then we perform a business logic testing that is  a test where we understand for example if there is a workflow inside the application  and to execute a particular function I have to go throughout step 1, step 2 and step 3.  What if from step 1 go directly to step 3? There is some mechanism inside the application  that verify that I have to do the step 2. Then we go for data validation testing. Here  as I say there are the main vulnerability inside the application because the application  are full of entry points and it is very difficult to verify all the entry points and validate  correctly the output, the SQL query, the held up query and so on. So here for example is  a reflected cross-excripting where in this site there is a search field at the bottom  and what if I write something like that instead of home, I research for home or something  like that. Maybe I can insert a script and if the output is something like that I understand  that the application does not validate the output. The stored cross-excripting here for  example we have a chat where you can see when you can insert a title and message what if  the application permit to write an HTML and then you post something like that and then  when a user click on test cross-excripting we will execute on the browser the script.  So for example I can store the, I can steal the cookie of the user or I can manipulate  all the browser of the user. Okay, command injection. Here an example from where I got.  What if there is something like that in which I request a file on the file system and simply  add something like that. The result here is something like that. You access to the file  but you can access also to the volume of the hard disk. Then we do web services testing.  There is a plugin inside web scarab that is very useful for the view WSDL. So when you  find the service you can use this plugin and you can insert maybe you can see here something  inside the web service and understand how the web service can answer to your request.  Here are some XML structural text. For example if I invert the tag of the XML request. Here  if I insert a large payload of the inside the XML what is the answer of the service.  Then I will shortly introduce you the web application testing. Then it's important to  have a testing report model. So we create a always pretty scripting model. It's very  easy. Risk is equal likelihood for the impact. We need to identify a risk, get information  about the vulnerability, the trade agent and then understand the impact of the successful  exploit on the business. So we can understand what to fix, what are the risk models, etc.  So here you can see the writing report that we can suggest is something like that. In  exactly summary a technical management overview and assessment findings and a table where  for each category of tests you can see all the vulnerabilities, the name of the vulnerabilities  and where is the effect item, where are the findings and the solution and the evaluated  risk about the vulnerability. Okay so how can you improve software development  lifecycle? The OBAs guidelines can help you to develop web application in a more secure  manner. The building guide tells you how to develop the web application to protect for  SQL injection for example. The code review guide tells you from a white box test point  of view how to test the function that you are implementing. So viewing the code understand  that there are security risks. And the testing guide tells you how to perform SQL injection  once that you have developed the web application and you don't know nothing about your web application.  So inside the software development lifecycle we can divide in five phases from the defined  design, the deploy and maintenance phase. The controls to implement are training on  the user to do policy review guidelines, adopt guidelines, doing code review and doing web  application penetration testing. So here is a big picture about the SDLC and OBAs guidelines.  On the left you can see that before the SDLC is improved the OBAs guidelines can give you  an help on how you can create your development lifecycle. And then in the defined and design  phases you can use the building guide to develop a secure software and in the development phase  you can use the code review guide and before the deploy using the testing guide that just  described. SDLC is not a buy two bucks to buy because you know it's a very complex process.  And okay, just a flash about the PCI standard and the OBAs. You can see that the control  6.5, the PCI standard tell you to use the OBA standard inside your application that you  are collecting information about credit card number and so on. So this guide is useful.  We think that this guide is useful for the industry, for the pen testers, so the company  that do audit of the application and for the clients. So we have a methodology that is  open and shared between the client and the the audit. Future steps. In OBAs we would  like to integrate better the develop the code review and the testing guide and improve the  client side security. And okay. So I thanks all the authors of the version 3 of the testing  guide and we have one minute for the answer, for the question and answer.  Inside an organization. Yeah. We saw that many companies require web  application penetration test. So the black box approach. But we know that it's the last  step that we will have to do. So our idea is to begin to implement the control in the  first phase of the software development cycle. So from the guidelines and the code review.  So we know that doing code review is more effective than doing web application penetration  testing. So your answer is correct. The code review is better. It's better because you  can see the code. You can see everything about the code and see okay in this line, in this  component you have a problem. And you can write down the remediation immediately. And  instead if you do a black box code, a black box assessment, you know that there is a vulnerability  but maybe you don't know where inside your software. And it's more complicated and it's  in other phase of the development. So more cost and it's okay. Other questions? Thank  you very much.
FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_0_131.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_132_179.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_180_779.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_780_7427.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_7428_7751.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_7752_9599.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_9600_10631.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_10632_16331.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_16332_18767.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_18768_18851.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_18852_18911.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_18912_18959.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_18960_19007.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_19008_19055.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_19056_19139.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_19140_20015.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_20016_20471.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_20472_20531.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_20532_23003.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_23004_23591.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_23592_23663.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_23664_24959.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_24960_25163.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_25164_26159.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_26160_26207.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_26208_26267.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_26268_26399.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_26400_26447.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_26448_29135.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_29136_29927.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_29928_29987.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_29988_30479.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_30480_30539.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_30540_30971.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_30972_31475.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_31476_31811.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_31812_31895.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_31896_31967.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_31968_32027.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_32028_32243.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_32244_32639.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_32640_32735.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_32736_33563.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_33564_39875.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_39876_40067.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_40068_46139.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_46140_48971.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_48972_64847.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_64848_70955.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_70956_71747.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_71748_71939.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_71940_72839.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_72840_73523.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_73524_74423.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_74424_74687.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_74688_75323.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_75324_75995.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_75996_76379.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_76380_76511.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_76512_76619.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_76620_76667.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_76668_79367.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_79368_79415.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_79416_79463.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_79464_79511.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_79512_79559.png FOSDEM_2009_OWASP_Web_Testing_Methodology_aOcgiTaujQE_79560_79624.png