 Dobro dobro, imam Mateo Mejuci z HoVasp. Moj počut, da se počutim, da se vse zelo. To je mnogo počutim, in je to, da se vse pravimo, da se zelo. Da se počutim, da se vse vse zelo. In da sem počutim v Italy, in Vologna. in bolonija. Zato to je taj agenda. Zdaj sem vse začetniti ovas projekte in ovas testov, kaj je metodologija začetniti sekuritivne aplikacije. Zdaj sem vse začetniti aplikacije. Zdaj sem vse začetniti sekuritivne aplikacije v tešku dovoljevacijo vsakrčen, danes vse taj vse začetniti. Zdaj sem vse začetniti sekuritivne ovas-petali v 2005, naredil taj projekte z dvej ročin, pomežajte začetniti sekuritivne aplikacije. Zdaj sem vse začetniti ovas? Vse začetniti sekuritivo. Ok. So, OWASP stands for the Open Web Application Security Project and is a project dedicated to find and fighting the causes of in secure software. So we have an OWASP foundation and everyone is a volunteer inside OWASP, everyone can participate. So everything we do is free and open source. So maybe that is for reason that we are here now. Ok. So the main object of OWASP is developing tools, standard and documentation related to web application security. We have thousands 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 OWASP 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 OWASP top ten 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 vulnerability and how you can protect about it. Then we do training, we do conferences, so 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. Softer also the other is free available on www.owasp.org. Then we have a community, we have a lot of chapters and we have a lot of project 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 OWASP building guide that is a guide that tell you how develop SQL software. There is a code review guide that tell you how to review the code for the security. Then there is another project like horizon that is a tool that do static analysis of the code. 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 king 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 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 the OWASP 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 documentations 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 lyulu.com, the book that is at the price of the printing. So it's less than $10, something like that. OK. So, now we will talk about the testing guide. Just a little history, the testing guide start from January 2004 from Daniel Kappber, the bright, 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. And in December 2006 we decided to develop a new project that is the version 2 that is more and more big than the other version. And 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 OVAS testing? We would like to create a complete new project focused on web application penetration testing. And 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 involved in the audit of the application a common methodology. So the question is here to develop a methodology that is completely open. OK, here the action plan, the last version, so the version 2, takes about three, four 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 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. We review the articles, review all the guides and then we write it in doc format and PDF and then we release the candidate and so on. The testing guide version 3 started on every 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 the article 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 in the PDF. You can see there is introduction, et cetera. 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 the vulnerabilities on a web application, we decide also to write a methodology to describe how write a report, how to collect the vulnerability, how to value the risk associated with each vulnerability, et cetera. 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. We have a SQL map, and so on. Then the reading, the fuzzing vector, and the encoded 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 10 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 overstesting framework, and so on. And here you can see that we start from the information gathering that is the first category of the test. And is the passive test, and 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. In here we have split it in 10 controls to perform. The first one is to perform the credential transport over an encrypted channel. For example, 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 respond 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 of guessable attack. OK, 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 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 suffer from data validation vulnerabilities. It's quite impossible, because here we test all the entry point 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-site 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, not in the environment. The application is running, so it's not very important to understand the software of the 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 Ajax. And then chapter 5 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. And 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 function is called, et cetera. You can understand everything about the code. Here we don't know nothing. So the methodology described here with the tool is together web application testing. Our approach in writing the guide is open and collaborative. So everything can give is contribution and collaborative because we decide together what to write and it's 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 parallel 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 paragraphs about the cross-site scripting. And here we describe what is 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 reflects 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. Here are other examples. And here are references. So you can read the white paper and the tools. Here, again, web scallop. And all was called 9,000 is another free tool that is a collection of web applications for the cross-site scripting. So you can use it, et cetera. OK, here the difference, because we described 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. 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 introduced 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 tree of the application, so all the directory accessible from the public, et cetera, 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 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, et cetera. 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, et cetera. 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 answer 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 DBLH 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, found 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 maybe you can do other kind of test. Here, for example, we can find an access to Tomcat admin interface from the internet, maybe. Or here, from Nestus output, 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 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 QQI attributes. For example, if when I authenticate on an application I understand if I go to see if when the directive set QQI I go to see if the QQI is secure, is HTTP only, if there is a date in which is valid or not and these are all attributes that you have to put on your QQI. Then we test for session fixation for exposed variable and cross-side-quest 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 these 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 QQI 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 QQI, 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, for example, using web scarab you can collect a lot of cookies, 101,000 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 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 cookies 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 and password, but from the ticket and the ticket is related to Mario Verdi and not Mario Rossi, so Mario Rossi and you can see the account of Mario Verdi. This is an example of session ejecting. Okay, another example here, for example, in 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 has 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 server let 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 cross-site request forgery that is a 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, and this is only for the admin, for example, or there is a found transfer, for example, 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 fund from my found to another fund with 10000 euro of 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. For example, online banking. Here is the transfer fund mechanism. You can see the HTTPS, examplebank.com, the transfer function in which the variables are EU and 2. This is 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 the HTML I insert the exact request that I understand that the application is used for a transfer money, I can force a user to request this one. 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 does not understand that he is doing that. And the application sees that the correct user is doing that. So it is a big problem for say, hey, I didn't do that, but the application sees that you are authenticated and you are performing that action. So it is a big problem to understand that you are not requesting 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 a question, please, because I see, OK. 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 for bypassing 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 analyzed 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 patroversal, for bypassing authorization schema, and testing for privilege escalation. Here, for example, here, you can see a site where you can download something, for example, from the file 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 file system of the web application. Here, for example, you can see a cheap pass vd. So all the running process, et cetera. Here you can see how to bypass the authorization schema. So, for example, the 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 functions, 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 use an hidden field with the profile value. You can see sist inf1. And this value is the authorization parameter. And once again, is given on the client that everything that is on the client is avial. So you have to verify that before using this information. And what if the user modified the value from sist inf1 to sist inf3. And in this case, we understand that 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, OK, I ran it a little bit, 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 the step 1 go directly to step 3? And there is some mechanism inside the application that verify that I have to do the step 2, that another test. Then we go for data validation testing. As I say, you can find the main vulnerability inside the application, because the application are full of entry points, and it's very difficult to verify all the entry points, and validate correctly the output, the SQL query, on the Heledap query, and so on. So here, for example, is a reflected cursive scripting 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 doesn't validate the output. The stored cross-site scripting, here, for example, we have a chat where you can insert a title, a 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-site scripting, 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. OK, command injection. Here, an example from a web 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 plug-in inside WebScarab that is very useful for the view WSDL. So, when you find the service, you can use this plug-in, and you can insert, maybe you can see here, something inside the web service, understand how the web service can answer to your request. Here are some XML structural texting. 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 prescrating model. It's very easy. Risk is equal likelihood for the impact. And 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. OK, so we can understand what to fix, what are the risk modes, et cetera. So, here you can see that the writing report that we can suggest is something like that. In exactly summary, a technical management overview, an 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. OK, so how can you improve software development in the lifecycle? The OVAS guidelines can help you to develop web application in a more secure manner. The building guide tell you how to develop the web application to protect for SQL injection, for example. The code review guide tell 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 tell 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, develop, 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 OVAS guidelines. On the left, you can see that before the SDLC is improved, the OVAS 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 SQL 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 to buy because it's a very complex process. And, OK, just a flash about the PCI standard and the OVAS. You can see that the control 6.5, the PCI standard, tell you to use the OVAS 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 audit. Future steps, in OVAS, we would like to integrate better the develop, the code review and the testing guide and improve the client's side security. And, OK. 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. If you could repeat the question. Yeah. You also said that we can have a wide box approach. Code review, look at the code and see if there are really opportunities for the code. What would be the balance to do between the wide box and the black box approach? Inside an organization. Yes. We saw that many companies require web application penetration tests, so the black box approach. But we know that is the last step that we have to do. So, our idea is to begin to implement the control in the first phase of the software development lifecycle. 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 because you can see the code. You can see everything about the code and see, OK, 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 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 another phase of the development. So, more cost and it's, OK. Other questions? Thank you.