 He is an electronics engineer and he is going to tell us something about building offensive web security framework in Python. So can we have a big round of applause for him? Thanks. The intro was sweet. I was an electronic student, I graduated. So the thing is, I submitted this talk after some long time, I got a notification that so and so talk got selected. And I was like, I looked at the title and did I really submit this long title? I was not sure if people would actually turn up because except this word, nothing else makes sense for most of the people anyways. So just before starting one more thing, I was just looking over through one of my demos. The network we are on is not completely secure. So someone is trying to spoof some packets. So if you are having any tunnels or VPN stuff, your company stuff, better not to do that. There are people who are sniffing on this network. So just be careful. If you have a VPN, it's cool. Yeah, let's get started. So a bit of who am I? So I was, when I submitted the proposal, I was a student, now I work at Yodly. So these are the things that I do. This is my first developer conference. I usually speak at security conferences. So I don't wear a mask, please. So we get branded like this all the time. When you think of a hacker or someone with a security domain, you'll think someone like this. These are the images you get when you Google for a hacker. So more or less the agenda for today is I'll just give a brief introduction to one organization which is OWASP. And then we'll see if we really need a security tool. I mean, there are lots of tools out there, right? We have Veracode, we have what not. We have IBM AppScan, whatever. Do we really need something more? What might be the answer? Yes, because I'm giving a talk, right? So then we'll talk about some of the modules. The aim of this talk ultimately is whosoever developed this tool are non-programmer folks including me. So the thing is we, the security community, we want you people to come in because we don't know most of the jargon link. The code we write is not extremely optimized. The code we write is, let me tell you, I really hate to write unit tests. So that's not a sign of a developer. So more or less the catch is at the end of this talk, you must be able to build, you must be at least be able to conceive an idea of a security framework or somehow some Python script to test your tool, test your software kind of thing. What is OWASP? I mean, how many of you have heard of OWASP? Okay, how many of you, I mean, most of you might be developers, right? How many of you people hate your company's security people? Seriously, I should change my organization then. Okay, so somehow this is an open source organization. What they do is they promote open source tools, they give some standards. They do lots of good stuff so that you can use their products to keep yourself secure. When I say products, it's not commercial, it's completely open source. Few things you might have already known are OWASP and OWASP zap. Top 10 might be pretty famous because everyone checks for top 10 nowadays. Like that was not the case few years back, but now everyone checks for it. So how many of you have ever heard of a cross-aid scripting or an SQL injection, wow, which is beauty, right? Okay, so how many of you have been at the defending side of an attack? Like, you were facing an attack, you were aware of it. And how many of you were on the defending side, okay? How many of you were on the side when you know the attack has been done? Now you have to clean up. How many of you are there? What is painful, defending an attack or cleaning it up? Exactly. So the thing is, prevention is always better than cure. So secure your apps first before anyone else breaks into them. It was kind of interesting with the Go! I've ever talked that their whole API is public. It's really not good, trust me. Yeah, so what is an ideal security framework? Why do you need a framework in a company? Okay, so one of the things is, there are lots of tools, okay? You develop your software, awesome, your QA team test set, fantastic. So now, there are lots of good tools out there, both open source and proprietary, which are useful for testing your product. Let it be source code scanners, let it be web application scanners, the black box tests like IBM app scan and stuff. Let it be source code and like veracode and stuff. So one is that the other thing, these tools are not really updated all the time. So no tool is a silver bullet, okay? No single tool solves all your problems, all the web application problems. One more thing, and the other thing is you can run all the tools, but it usually turns out to be pretty manual. So you run a tool and then it somehow like gives a report. You run tool two, it gives a report. You run tool three, it gives a report. Now what, what? Everything sits in a folder or what? It's nothing, you have to see the actual result. But the problem is time. As you say, when you do releases like three to two to three releases a day, you don't get time to go through reports of all things. Like if you run veracode on just a shitty code, it will give you some minimum of a thousand vulnerability saying this and that. So you should have an idea of, you should be able to classify like not you, your program or your tool or framework should be able to classify the findings. Telling you that boss, this is important, go have a look at it. Go fix it, again run that. So one more thing was, yeah, scheduling capabilities. Yes, it's good to have a framework which actually finds, when it finds rated vulnerability, it mails you or it sms you something. The last one, yeah, people like tools are not built for that kind of purposes. I get a lot of messages saying that. So from a developer perspective, if we see for such a dream framework, what are the main modules that we'll always have? So most of the talk will only be talking about Python. So the first thing, if we classify our tests into plugins. So one test is one plugin kind of idea. So we should have a core engine which actually takes care of running the plugins and then saving the output and all the stuff. And then we'll have Requestor. Requestor is some part of your framework which actually controls, I mean, which actually helps you to make a request. Why is it so important? We have URLlib, we have the beautiful request module. Why should we have a separate Requestor module, a separate one more module in your framework? Why not just import request, request.get wherever you want? Apps are not really simple, my friend. So what happens is one thing is session awareness. So there are cases when you have to do tests after logging in. So it's not that every time you import request and then do all the 45 requests which actually logs you in and then do the actual test. It shouldn't be like that. That part, the logging in part and all the stuff should be taken care of your framework and not by your actual plugin code. So, and then there should be some plugin API. So for this, like when you write these plugins, you should have some API exposed to the plugins. So you can actually write that, okay, do request to this. Now check if there is something in this, that kind of stuff. And then you should have a UI, that's the whole point because you should be able to view things quickly, right? And then you should have a proxy. Why a proxy? Because lots of tools do lots of stuff and you never know. Like 99% of the security tools will never tell you what they're doing. They'll run bunch of tests and then they'll tell you what all they found, like what all they think is vulnerable. So they might have missed something or the test might have crashed something. So you should know what all the tool did. And the last thing is, what are the interesting things these days? So the thing is a vulnerability comes out, a new one, okay? Something in Ruby on Rails, let's say. So the company doesn't have time to patch it immediately. So what they do is they deploy a virtual patch, which is kind of a WAF. They put on a firewall and they think they're safe. So there are like, the ideal thing is if you deploy a virtual patch, you should actually test it for its effectiveness first. So we'll come to that on how to test that. So more or less with the previous methodology in mind, we actually, like Abraham was the one here, so he actually built a tool called offensive web testing framework. The interesting thing is, if you take only the first alphabets of each word, it will be OWTF, okay? So, and the main aim was simple, penetration testing to be pretty efficient. Penetration testing is what you all know, I hope so. And the next thing is to standards like OWASP and all that stuff. So the idea there is to have a checklist kind of thing, okay? So ultimately you should be able to like, okay, I checked for XSS, cool. There were no XSS. I checked for SQL injections, cool. There are no SQL injections. I checked my JSONP endpoints, nothing. My mom is calling. So, and then the framework was written in Python too. We'll just have a small video. So this is the interface more or less, the framework has. So you can add, I'll show you. You can add targets here. So this is more or less from a penetration testers perspective. So how we use the tool. So you can run some plugins. There are some 150 plus plugins, so. So you can see one of the plugins. It's a robots analyzer, robots.txt analysis through party size. How many of you think robots is bad? I mean, how many of you think entries in robots is not a good idea? Like, it depends, yes. So the thing is, there is a lot of information disclosure if you don't put it properly. So put all your sensitive content into one of the folders and disallow everything under that. So it's not that you put everything out and blacklist them individually. So what happens is an attacker can just have a look at the robots.txt and tell that, okay, he's hiding something, let's go there. So this is more or less the thing that does it. If you observe like four plugins, the same category, they do the same thing. Why? Isn't it redundant? The thing is, it's not actually redundant. There is a category, I mean, type of plugin here. So the semi passive category actually says that, okay, I'll just send a get request, get the robots.txt and analyze it. The passive thing, the framework will not send the request directly. It will actually ask a third party. There are many services which actually let you do some calls to particular URL. So the semi passive thing, semi passive thing makes a direct call. Passive thing makes call through a third party service. Grab will do nothing. It will just see the, like it will check for robots.txt file in your transaction DB, the all the transactions that you're already connected. So, and the last thing is the external plugin for helping. So you can select something. You can run something. You can do, so you can launch in groups as well. Okay, here is one of the web vulnerability scanners. This is another web vulnerability scanner. It's quite famous. Some of you might be using it. So the plugins are running in the background actually. So now, yeah, this is how the report looks like. If you click on it, so we ran one plugin, other two types of one plugin. So then we can see what's the actual result is. So based on the finding, we can actually rate our rankings on the side. So, see, that was the third. So it found all these entries in the robots. So this was the robots.txt that was downloaded from Facebook. Okay? See all these entries and the actual request that I mean was done for this. So if you see, you can actually rate it here. Those are different rating scales depending on what you found there. You can add your own notes. It's the same thing, but it was, this request is done directly. That was done through a third party thing. Again, the rating. So what helps is at the end of the run, you'll be actually having rated vulnerabilities. So you can actually filter out the only the high rated ones. So you see a info flag over there rating that the highest rated vulnerability for that site is an inforated bug. So this is the place where all the transactions get recorded. The transactions are recorded. So whatever tool you fire through the framework, all the transactions, when I say all the transactions, all the HTTP transactions go through a certain proxy. So the proxy stores everything for you. So you can actually do lots of stuff. So you can search. Oh, it was not Apache. It was IS, I think it was IS. So you have all this stuff. We can search among all the transactions. The thing is tools will no more be transparent to you. You will know what the tool is actually doing by seeing the request. More or less, this is how it goes. So the thing is there are few other facilities like workers and work list. So the idea is, let's say you're running a tool and this happened many times. The site actually crashed, but you are halfway. Like some of the tools take more than a day to finish. So we have something called pause thing. So what it does is all the tools, just for an idea outside our scope, so we run them in a separate process. We don't run them in our own process because if they crash, then we crash. What's the fun in having a framework then? So the thing is when we run them in a separate process, so when we think the site is down, what we do is we take a snapshot of the process, store it, which is ideally nothing but Linux signals. We just give it a Linux signal. It will pause there. So we'll keep on checking the target and the target is back up again. We'll just resume this process. This will go on again. So that's the beauty of Linux. So it's just a neat trick, nothing else. This is more or less the basic architecture of how the framework is, or WTF. So you have an interface and API server which actually serves the users, the API and the web UI. And then part of this server itself is a worker manager. These processes are actually the main units which run the plugins. So when plugins are run in this workers, the traffic is sent through a proxy server. And this gets logs in the transaction, by a transaction logger process that logs everything through a DB. So ultimately, anything and everything is available through DB at the endpoint. So that is how you saw the transaction log there. This is more or less the UI that I showed you. Some few of the Python libraries that we use. Tornado, I'll tell you why. PyKal, Common, SQLAlchemy for ORM. Remember, we are not performance freaks. We are not like GoIB for serving people. We want to build a tool here. So we use Selenium, Beautiful Superpassing. All this stuff are part of simple security testing if you do sometimes. So as I already told you, this is the classification of the plugins. So the plugins are actually classified based on their aggressiveness. So why classification and aggressiveness? I don't know, like if any penetration testers here, the thing is you need to have a written permission before you actually go on for a test. And the thing is you don't have much time once you get the permission and all your manager gives you is a URL. So the problem is before, I mean the time period between getting the URL and getting the actual permission, you can do certain non-intrusive stuff which are completely legal in India. So when I say non-intrusive, nothing. Just go to the site, see what it does. What happens is when you do that, all the requests in the background are actually recorded to your proxy server. And then all the grep plugins, all the passive and all the grep plugins which actually analyze all the transactions, they'll find something or the other if there is something. I'll tell you what they will find. So we already saw what all modules were there. So this is how more or less how the core audibility looks like. So we have this thing called core object. Do that object, all these things are attached. So don't hit me. This is not the optimized way to do thing in Python. You can do service locators and all this stuff. But this was built long ago. We are kind of, as you say, renovating again. But this is how it works as of now. So it has all these modules attached to it. So when you want to write a plugin, the thing is you only have to write a method called run and that, I mean you have to write a function called run and the function will get the core thing. So you can see that if you have core, you have access to everything. So it can do file IO, it has access to plugin API, it has access to requester, it can do, it can run commands directly using shell, it can access DB, it can access plugin handle. But it cannot access interface and API server, the thing is because it runs in a different process. So when a plugin runs, it runs in a worker process. So not ideally it runs here. So even though it has symbolic access, it cannot do anything because the process might have forked out long ago. So yeah, so here this plugin does nothing. What this does is it actually runs a vulnerability scanner. So you can see that it is actually calling code or plugin helper, plugin helper is the plugin API that we expose through core. So it actually is asking to run a command. The command is obtained from resources. So this is more or less how our resources are. So here you can see, as I said, the passive resource for this thing, at the end you can see that this is something using SSL labs and there is a parameter using triple add rate. So it's actually a position holder. So when you run this, when you use this resource in a plugin and the plugin is run against a particular target that is automatically replaced by your host name. So all you have to do is click on the link if there is any vulnerability you'll get it. So we are trying to make people more lazy. So that is our aim. So and then we have the same thing open SSL and hardblades can and whatnot. Okay, so many stale faces. Why a framework? Why not run tools directly? Can you imagine, like how many of you are Java freaks here? That's, no, no, no, like we should know. I'll tell you why. So this place, things get picked up. So there are lots of vulnerabilities get released on a daily basis. I'll tell you what you have to test for. So why a framework is simple? If a new vulnerability comes out tomorrow, your framework should be able to test it. So you shouldn't run to a security tool guy saying that, dude, I want this support. Your tool doesn't do that. He won't even respond. Trust me. So the thing is, if you built such a framework easily, what will happen is, let's say, how many of you are aware of this attack? Like anyone have ever heard of this attack? Wow, one. And that's like four, five months back, dude. So the thing is hardly it, because everyone makes it popular, right? Things slip by. So what this attack does is, all your JSONP endpoints are actually vulnerable. Why and how is the point? So in JSONP, what happens is, you give a parameter that gets returned as a function call in the response so that you can directly do a call, right? That is the main idea. So what all characters should be allowed in a JSONP, that thing? Ideally, A to Z, small capital A to Z, numbers 0 to 9 at max. Nothing else, right? So you are giving alpha numeric capabilities. I mean, you're actually taking the parameter from there to here. No other sensitive data. But the thing is, there is a subtlety in the flash player. So one of the guys found that you can actually build ASCII flash files. So he'll give a very huge parameter, okay? That is the actual flash file. He was successfully able to convert the bytes, you know the binary how a SWF flash file looks like, right? So he was able to convert it to an ASCII one, a pure ASCII one. So the thing is, when you put that in the get parameter itself, you'll get that thing will completely get, I mean, reflected back in the response in the first part itself. What if I load this JSONP URL in a flash player? The flash player will think, it's a valid flash thing because that is how he built it. So ultimately it will play the flash file. What's the big deal? You are just embedding someone else JSONP end point on your domain because you don't have access on their domain. You are embedding some others JSONP end point on your domain in a flash player. What will happen? Go on. What is cross domain.xml? Ah, yes, XSS, why? Because inherently beautiful Adobe Flash will allow you to make request to the domain from which you are being served from. So you actually broke the SOP thing there. You're actually making calls to some other site from your site just using a flash player and the JSONP endpoint. That was the attack. It's not pretty tricky, but checking it is pretty simple, I would say. So ideally, if you want to write a plugin, like let's say you have a framework, you have your product, the thing is these are the small things that your plugin API should be this good enough that, so your plugin should actually search the transaction DB. It will ask the transaction DB that, okay, give me all the requests which have a JSON response type, response content type. And then I'll just take each URL, first each of them, and see if my thing is actually getting reflected there. And if it is getting reflected directly, then the attack is possible there. So can you see what is happening here? Ultimately, you are testing a new vulnerability with just maximum of five, six lines of code. So you are actually increasing your coverage, I would say. So yeah, looking into the modules that we saw earlier, we have some interesting stuff. We have some interesting modules which we built across the time. We faced few challenges while facing them. One of it was an HTTP proxy. Writing a proxy, my friends, is not rocket science. It's pretty easy. If you understand what it actually does. So we actually picked up Tornado. In literal sense, I can tell you. So translating this into very common language, it's like we built a proxy using Django. Why? I mean, Django is an application server, right? How can you build a proxy using an application server, an application framework? What does a proxy do is the most basic question, nothing, it gets your request, it does your request on the actual site, gives back you the same content. Simple, we did the same thing, but why we picked Tornado was the thing is, we did some pre-implementation research. So based on the speed, based on the support it does. And as I already told you, we are security guys. We don't want to implement all the request parsing code. We never wanted to go through all the RFCs which mentions all the byte characters and all the stuff. So these were some of our requirements. We wanted the proxy to have caching. Obviously, we needed the ability to manage the middle and SSL connections. Yeah, this was one of the big challenge again. So serving WebSockets and HTTP, serving HTTP, HTTPS, WebSocket, WebSocket secure on the same port, it's a bit tricky and yeah. So this was the benchmark that we did after building the proxy. So all Python proxies. So what MI stands for is multi-instance proxy. So on the left side here, the thing you have is request per second, average request rate, average request per second. So you can see how well the thing scored, a multi-instance R proxy scored. The main reason is simple. It's just because, I mean, the thing is, we actually did quieter research before trying to build a product, trying to build the proxy. We did a lot of checks on it. That is one of the reasons. So how the caching works, it's pretty simple. In multi-instance proxy, generally it has four separate instances. It actually uses the file system as a cache because everything else is slow. Why? Again, we will be running four or five tools at the same time and the traffic that they generate is pretty huge. So bottlenecks, even though optimization is not one of our most primary concerns, for proxy it was because if we slow down here, what happens is all the tools slow down. So ultimately you have a huge latency in your whole tool. So this had to be fast. We couldn't find anything other than files. So why when we have all the big caching names and all the stuff? We are poor security people. So all the tool we build, I mean, the tool we run, I mean, the tool we build should be able to run on a single system, on a attacker system. It shouldn't be like, I deploy it on somewhere, I have four or five servers as it's caching servers and I have some messaging queues and all the stuff. We don't have all that equipment. So it has to be on one server ideally. This is how SSL MITM works more or less. So the thing is, you create your own certificate authority, you ask your browser to trust it and then you use that certificate authority to dynamically intercept all the SSL sessions. So ideally in an SSL session scenario, this is what happens. Some of you might not be aware. The thing is, when you go to an airport, plug in your charger somewhere, if you see a stray charger, plug it in. If your root debugging is enabled, what happens is, it will install a self-signed CA on your mobile, okay? And then, my friends, you will use the Wi-Fi thinking that, oh lord, I have good certificate store. There is no issues. I have SSL enabled, like TLS, I'm good. You'll browse, but you'll never know that your traffic is already being intercepted heavily. So be careful when you use stray charging ports and all the stuff. This happened really, that is how I'm telling you. Supporting HTTP and WebSocket are the same thing because if you can relate it to, Tornado has different classes for handling HTTP and this thing, WebSockets. So how to write a single handler is just by this. So we have this magic thing called new, which actually gets called even before you're in it. New is actually the method which will return you the instance. So there itself, we check for a WebSocket kind of request in it and then if it is such one, we'll return our WebSocket handler. If not, then if it's not a WebSocket request, then we'll return a normal HTTP request handler. So this was one of the cool things that we found. The second thing, which is interesting to implement in your framework is botnet mode. Why? Some of you might be working in finance industry. So they're quite stringent people. If you do two, three aggressive requests, they'll block you. It's no fun in testing them, right? So the thing is in botnet mode, your request or the request made by your tools will be spread all over the internet. So the algorithms has to be really good in order to detect a sequence there. So it's a quite cool thing. The extension of botnet mode is Tor mode, which actually uses the Tor network itself. So after a particular period of time, it will renew the IP directly. This is one cool feature if you are planning on implementing a framework yourself. This one is WAF bypasser. Again, it's one of the tools that, like one of our guys wrote, one of our devs wrote. This is actually integrated into OWTF as a module, but this is available individually as well. So you can see here, you have fireballs everywhere, right? So while development of this tool itself, a zero day was found. How many of you know what a zero day is? Cool. Zero day is something which is not reported to anyone and not fixed, okay? So here in this video, if you see, he's actually running a WAF bypasser and he's actually specifying that, okay, this is a post request with username key and the value, he's specifying that, okay, first here, what he finds is pretty interesting. So it will actually run against all the encodings, all the possible stuff, all the possible permutations and combinations and it will tell you what all HTTP requests were detected and what all HTTP requests were not detected. So it will based on a string or based on some search on the response, it will tell you which of your intrusive requests were detected by the WAF and which were not. Then you can see A code was detected, but at the same time A code, A was not detected. So there are cases when you might think that, okay, the virtual patch is there, but it's fine, it's not actually. So here he just tried code and it blocked it, okay? And then he tries A code A or something code something and he tries that ideally it shouldn't detect. So he doesn't detect. So the WAF didn't detect. You can see, right, when WAF detects there is a different error message most of the times. So it is actually again defense in depth if you want to show the same thing for both the things. One more thing, if you are planning to build a framework again, you already saw in the video that I had to go through each and rank the findings. So that was again making us do work. Again, lazy mode applied, we wanted a tool which will parse other tools, the tools we run, all the reports and then based on the severity that they give will rank them. There are two ways in which the ranking is done. Like these are the tools that are supported. So programmatically, this is how it is. So it has one huge parser class. It has all the, it has abilities to parse everything. I mean, all these formats. So ultimately adding a new support to a new tool is nothing but just adding a small, I mean extending the base parser class. The rankings, it does in two ways. One, some of the tools give their own rankings. So they have info, something, something levels. So we kind of normalize it onto our scale and then we give, suppose if they are giving on scale from one to 10, but we have a scale from one to five. So we normalize it down. So this is one way. The other thing is, let's say the tool doesn't give any, this thing, any rankings by itself. So what we do is we have a signature file which has some matchings, I mean, which has some hard coded stuff saying that, okay, if this is found, then the rating is high kind of stuff, simple things. So it does it. So one of the last interesting modules is an Ajax spider. Why do we need an Ajax spider first of all? So the thing is, most of our stuff these days, most of the web applications are pretty complex. They're pretty dynamic. The attack I told you previously, the JSNP attack actually occurs only on JSNP endpoints, right? So if your coverage on dynamic web applications is complete, only then you'll get hold of such requests. So you should be able to like, okay, the one thing is you hire a person, make him sit and make him click on all the links manually in the browser because you cannot do it directly using requests. The content load is loaded dynamically a lot of JavaScript has to run. Or you use an Ajax spider. But the problem with Ajax spider is most of the Ajax spiders are pretty naive. None of them are good. So they break on a lot of stuff. If you want to write one, these are the three things you require. You need a browser driver, preferably something like Selenium. Use some headless browser like PhantomJS, use Chrome or whatever you want. Use a graphing library because you need to know from which state you end up at which state. That is pretty important if you want to traverse the application. And then you need to have a DB driver to store everything. So how it works, pretty simple. So how Ajax spider works, it's go to a page. So here in the graph, each node is a DOM state. I hope you are familiar with what DOM is, all the backend developers. So DOM is nothing but the hierarchy of the page, something, something, something. So you have the arrows, I mean the edges actually connect different nodes. So ideally what happens is your edge will tell you from what DOM node you end up at what DOM node and the edge will also contain information telling which element and what action you did to go from that state to this state. So through this, the thing is from any state you can go anywhere, literally, almost all of the states, not end states like this. These are terminal states. Yeah, so this happened. The reason I built Ajax spider was pretty simple. So one of the applications had session tokens in the URL itself. You cannot reuse URLs in that case. So none of your traditional spiders work, none of the existing security tools work because the token is in the URL itself. So the crawler actually what they do is they start, even though they get all the cookies are, I mean they try to log in and then they get the cookies are even though they do a request to a URL, the URL is not valid because the session token is not there or it is old, so that kind of thing. That scenario, you need to have the whole state graph. There the thing is just remove the session token, complete the rest of the URL, complete the DOM states, then you can actually traverse the whole application. That is how Ajax spider is implemented. Once Ajax spider is implemented, it is awesome. You can actually, you have everything. Again, your coverage is complete. So you cover everything from JSNP endpoints to whatnot. So one thing is your crawling should be good or you should be a scumbag. I'll tell you what scumbag spidering is. We usually used to do scumbag spidering in OWTF. The word might sound offensive but it's pretty simple. So when we proxy all the tools through our proxy, we collect all the requests, right? So indirectly we have every URL that every other tool collected. So it's a superset of what all the tools know. And then if you don't want to build an Ajax crawler, use one which already exists. It's crawljax, it's pretty cool. It's written in Java and you can try if you want to. So before building another such framework, just a big heads up, please don't. It's a big pain. Why? Someone comes up, someone wants something, then they build something, they leave it off, they don't support it. And the community is more or less like, it's not useful for us any longer. So the main idea is contribute to something which is already existing. Like there are two other good projects called Golismero and there is one more called Faraday IDE, similar projects. So contribute to one of them, add the functionality that you think is missing to them. That way you add a functionality, you'll get what you want. The developers, okay, cool. People are using it, we are getting some requests. They'll keep developing the other functionality. So don't start building a new tool just because you want a new feature. That's a pretty bad idea. So use the existing ones. Yeah, even if you are building a security tool, please follow all the standards. We paid a pretty hefty price because we not followed this thing initially. So ultimately it's a software, right? Other than that, these are the things I spoke of. Everything is on GitHub. Whatever I spoke is open source, completely free. If you want to seriously build an AJAX crawler, it's quite difficult, but it's quite, I mean, learning process, because comparing DOM states is not easy. Just imagine there might be a date field, okay? There might be some other CDN link which actually changes. So there might be lots of things which change. So comparing two DOM states is a difficult job. You should see the, like, if you have some time, go through the research paper of crawljacks. Like that is pretty good. Like most of the tools which run on Java use crawljacks for AJAX crawling. No one has implemented their custom stuff, not popular security tools. So, yeah, crawljacks, and this is one of the alternatives to OWTF. It's a pretty good project as well. So I'll take questions from here. Anybody has any questions, can I ask? No, friend's Facebook account. Hello, my name is Jai Singh Shukla. Before humans, I was reading the OVA documentation for Python language. They have done, they are preparing in between half of, half of what are documented on the GitHub and half of what's still remaining in a to-do list. So according to you, what are the Python bugs developed or made in there most commonly and you find that this would be not there? Because OVA's are pretty much to-do list and there are some of them very goodly described. So according to you, can you suggest what are the Python bugs and security flow? The super native bug that every developer does is trust everything that you get from the client side. Regarding that, if you are, but then the documentation, there are like... That is a secure coding guide, right? Yes, yes. So that you have to code it securely things. So it depends on how, you should always be aware of what data, so there is this thin boundary between trusted and untrusted data. So if you are transferring data from one domain to other, you should actually filter it properly, carefully, I mean, cleanse it and then put it on the trusted domain. It's not that you'd consider any, like there are cases when developers, so I'll tell you what people mistakes do, from the programming side, I usually do Java code reviews, so Python, I don't know, but the general things that they do is they put some cookie, okay, and they think that cookie is okay, it's not user-manipulated. And you can do lots of stuff just using a cookie or similar things, saying that some developers say that we'll use referrer header for kind of checking if there is, I mean, if it is a cross-site request for your thing. So these are all the understanding of the developer. So ideally, the security team should be aware of all this and yeah, developer should also be aware of what all the catch is here. Secure, yeah, the data thing pretty much is that I could say that you should be careful on what data you're putting where. One of the bugs that I found interesting was, you know this thing, right, sub-process. So one of my colleague was telling me, there is sub-process, okay, and there is one particular method of it which actually escapes the arguments. So you can only run one command. You cannot do an injection there. Okay, that's good. But what happened was ADB was there. ADB was using this shell. Python was actually cleaning it up, but ADB was not cleaning it up. So ultimately what happened was, you could do a shell injection, but in the context of ADB, not in the context of the Python process. So it's more or less, you should know where the data is going and how the other program is treating it. Thank you. Anybody else has more questions? So you mentioned about running the proxy server, right? Is this proxy server being run on your local or? It's run on the local host, the same place where to. The proxy server will be started when your tool starts. It will end when your tool ends. That's it. Okay. I'm coming from a static code analysis background. So one of the biggest problems that I face is that too many false positives. Yes, yes, that's what I say. How do you, what are the best practices that we can follow to avoid these false positives? The one thing I learned in my brief three month at the Stintech, one of the company is you can never force developers. So it has always, it should always be on your side. So what we do in our organization is we have scripts which actually filter out some positives. So based on how your application is actually coded, you can implement filters. So in the period of time, you'll get to know what are the actual false positives, then you can actually filter them on your side. But forcing the developer never really worked for us. Like they'll repeat it. And yeah, they are on hard deadlines as well. So I think we should be the ones taking care of it. Okay, any more doubts? Here. Yeah. Hey, so I'm not very familiar with the security techniques here, I just developed code. But this is very interesting and I, every developer would want his code to be secure enough. I am looking at this tool as a way of abstracting my efforts of building a secure, secure code. How easy or how informative I have to be to use this tool? Okay, initially when this tool was built, it was actually for penetration testers, I would say. So most of the lingo that you will find in there, even the classification that you see is the OASP checklist classification. But with a bit of knowledge transfer, I think it will be same for any user. So a simple thing put, if I say, if you're the same thing, if the Rosetta Flash attack was found on one of your JSON pain points, the ideal fix for it is to just add a space before the thing you are reflecting. So Flash Player invalidates the whole stuff and all the things. So. Yeah, so I remember you mentioning Metasplite and all that. So I know about the, about, you know, I can go there and find out whether there's a vulnerability or not. Yeah. I don't do that very actively. Yeah. So the thing is we have one external plugin, which actually suggests for fixes also. So it won't be a generic solution. Because it doesn't know what language the server is using all the stuff. It will actually provide you to some manual resources where you can find information, more information about that particular vulnerability and how to fix it. How is it, how it has mitigated and all the stuff. Yeah. Do you also have a documentation? Yeah, the user documentation is there on docs.github, docs.odwtf.org. It's user, I would like if people contribute. Okay, so time is up, so you can catch up later. Sure. So anyone wants to talk anything security, security plus Python, I'm free, I'm all yours. Other than that, please contribute. One of the things we miss is contributions. Like we are all security folks with a bit less time on our hands. It's not that programmers have a lot of time, but still, please help us. Thanks. So please give a round of applause to Bharadwaj. And I would like to give this small gift to him from the PyCon team.