 So I'm Ankita. I work at LinkedIn as a software engineer. I have been a member of Nulcon Chennai. I've also presented at Nulcon in 2014. Hello everyone, I'm Anamika. I work at ANVAS Information Security Services. I'm author of ViHawk, which is a tool to find vulnerabilities in your router. I have been presented in a couple of conferences, including HIDB Amsterdam, Defconn Kerala and Nulcon. So before we talk about anything, I work as a developer. So whenever I work on any feature or something, I deliver my code to QA to find any unit testing cases which I have missed so that a functional team can find those bugs and report it to me. So when a product comes to me, I write some test cases. I automate some of them and after everything is green, functional tests, integration tests, backend testing, all the services are up and running. I give a green signal. We are good to go ahead and release the product. But when the release time comes, the security audit team comes in and they just fill our build. They are like, your build is not up to the security standards and we are going to push the release date till you fix all the security issues. So what is the security issues we come up with? So I'm pretty much sure this crowd here belongs to QA teams. So you might be not so much aware of web application security issues. So I'll give you a quick intro what are the web security issues are so that you understand what we are exactly talking about here. If we talk about web application, we all know web application are very crucial part of our life nowadays, just like Oxygen, for banking, shopping, everything we need web applications. And if your web application is not secure and safe enough, these beaches can lead to theft of data, malware infections, loss of consumer confidence. If you talk about loss of consumer confidence, you might have heard about the exploitation in iCloud which exposed all the private photos of all the Hollywood stars. Same way, failure to meet some requirements because whenever you develop any application or any product, you have certain security requirements that your product should meet to such requirements. Sometimes during development phase, you miss it and when your product goes to live, then a bug bounty hunter reports it to you, then your company has to pay a huge amount to them. Next is, again, since you pay them a huge amount, your application is compromised. And if you talk about certain surveys, they say out of 10 sites are vulnerable. So what are the attacks which takes place on your web applications? Very first is and major is SQL injection. SQL injection is nothing but trying to insert some SQL commands from your web UI. Another one is XSS, known as cross-site scripting. Third is denial of services, code execution, CSRF and many more. I wish I could have explained you everything over here, but since it's a Selenium-based conference, and the aim here is if you don't know anything about any of these kind of attacks, still, how are you making your application secure with your functional test cases? Most of us use things, okay, we have provided a securely tied password to our applications, so our applications or any email account is very well secure. But that is not true. Recently you have noticed that on LinkedIn, all the user name and password got published on the web applications, and it has all the details of the user name and passwords, and this whole database was somewhere around, I guess, 100 to 80 GB, which contained all the information about the LinkedIn users. Sorry. The question here is how will you protect your web applications from these attacks? Ideally, what an enterprise follows is they hire some security auditor, because maintaining a security auditor in the company is really expensive. So what generally companies do, they maintain a very small pen testing team into their company, which works on finding bugs on a platform, but majorly, they hire once in a while some expert security auditor, which tries to find bugs into their application. But this is expensive and time consuming as well. There is a certain scenarios where you are not comfortable sharing your company's confidential data with some external security auditor as well. The second approach is using automated web security scanners. We know that there are so many scanners available in the market. Some are commercial, some are open source. What actually scanner does, this is basically a set of programs, which interacts with your web application and try to find some inject points where it can insert some payloads. Again, about payloads, payloads are not some random data, which we simply type some random input and try it out. For certain type of vulnerabilities I have explained before, they are a set of defined payloads. So if web applications basically try to insert these payloads and try to find where your application is compromised to security, the plus point with the web applications are they are cheap to maintain, and second thing is you can run them 24 on 7. So as I told you how this scanner works and how easy it is to maintain in your organization. Again, about scanners, there are plenty of scanners and they have their own algorithm, their own analysis, and their own payloads. Since payloads are really huge in numbers, because for example, if you want to find SQL injections, there are not only 10 or 15 payloads to find SQL injection, there are possibly hundreds of payloads defined for SQL injection itself. So it is not easy for each scanner to include all the possible payloads, because it makes your payloads heavy. So when it tries to cross your web application, it becomes slow. And I must say, the worst part with the human is they don't want to wait. So you definitely want immediate results with your scanning reports. There is also a passive approach, like whenever any request or responses comes and goes, it observes your request and responses and their corresponding results. Web applications are also 100% not the solution of what we think of, that some integrating something with functional security with the security testing. At the end, these web applications are made for us, not for some automated scanners which put, give some random data and tries to click on all possible links and buttons. And for the sake of security, these are the major scenario where a human intervention is needed. If you're creating an email account, you provide alternate email ID and get a confirmation mail. If you deal with the banking sectors, you get OTP. And in some real-time scenario, you have to provide CAPTCHA. CAPTCHA is the word which you see in the login page. So all these things comes up with the session ID. So these things have our particular sessions and CSRF tokens. Based on that, your authentication gets done. So these are the changes you fail when you try to automate such some real-time scenarios, which is automated login, infinite websites. And in some pages where your website is really huge with the JavaScript pages, so in these cases, your web application scanner fails. So the from where we started to find the fix for our problem, we have not the exactly fix. So how can we hold all these problems which is coming with the automated web scanners? The very first thing is, when we talk about the crawler, crawler here means web security scanners. Sometimes they really crawl a lot your websites, which is not needed as per your requirement. Sometimes they don't crawl enough to find the security issues in your applications, which is again, in that case is what happens, crawler basically puts some random data, some random clicks. He doesn't know the exact flow. If you want to test the login page, it doesn't know that he has to provide some valid input username password and click on the login button. It generally provides some random username, random ID and click any random button available on the page. But if what if we provide these inputs to the scanner, okay, this will be the user ID, this will be the password, and as per the flow after providing password, you have to click on this login button. This solves one problem. It means your crawler is now crawling your site as per your requirement, but consider a scenario where you have thousands of test cases. Providing manual value for these thousand test cases is not easy. And from point of maintaining it, it becomes difficult. So the whole point, like making your functional testing in form of automation, is not received. So it's again time-consuming and inefficient. Better approach, we think of is every team uses functional test cases into their company to validate any product. And every enterprise has some framework to find it out, okay, this is the framework we use. And the majorly nowadays, people use Selenium and Cucumber. So we targeted Selenium as per our need. So we came up with the solution, what if we integrate Selenium with the web application vulnerability scanners. So we use IronVasp. IronVasp is our tool, which is basically web security scanners. It's an open source tool and it is one among the best scanners available in the market. It checks for again 25 plus security vulnerabilities. And in some parameters, it stands better than your commercial project. It's not the statement given by me. If we talk about the security industry, there is a site maintained by, okay, I'm missing his name, but the site name is said tool markets. So what this guy does, whatever the security tools are available in the market, he picks up all these tools, compare them in terms of their functionalities and their results and generates the reports. So as per this report, IronVasp stands at the better position than some commercial products. And here is the result which we expected in the beginning itself. We have valid inputs for our scanners now. It follows the correct flow at what, but after what input you are supposed to click where and how to follow it. And in terms of cost and time, it is effective to our team and every company. So this process of grouping together a series of steps and putting together in a flow and then scanning them is called as workflow scanning. It is a scan where a step-by-step procedure is followed. So if you're doing a login functionality and you're running it around thousand times, then every time a login functionality is performed. So every time a new CSRF token is generated which is not duplicated. So the problem where we cannot do a scan on HTTP secure sites, it's solved using workflow scanning. So let me give you a brief about Inverse demo so that you guys have a better understanding on how we can integrate it with our functional test cases. So Inverse interface looks like that. All scanners work on one principle. They fix themselves to a port, they attach themselves and they start listening to that. Once they start listening to the port, all the traffic that is passed through the port, they record it. Once all the traffic is recorded, they inject different play loads and find different vulnerabilities in it. So we got to set Inverse as a system proxy. Once we set system proxy, here you can see in logs, we don't have any log. Now if I open any site, there's a hosted site on my local server. So once I open it and I've set Inverse as a system proxy, all my logs should have been captured. So if I go to Inverse earlier, there were no logs. Now I can see two logs. In these logs, the request response headers and all have been captured. So if we can capture the logs which a browser sends, we can perform a security audit and our functional test cases do that. They run something on a browser and if we can capture all that data, we can do a security scan. So this is a very basic functionality of Inverse. So a simple functional test library which acts as a bridge between Inverse and our functional test case. So Inverse won't know when a test case starts or ends or where it has to listen to. Similarly, our functional test suit won't know how to call Inverse, where Inverse, on which port Inverse is listening. So we came up with this library and it is in a jar format. So we added to our build path, compile it and all the classes are available to use. Apart from this, we need to tell our test cases on which port Inverse is listening. So that can be configured by us and if we have some, the default port is ATAT and if we have some app running on ATAT, we can set another port and we can configure which IP and port Inverse will listen to. After this, we are good to go. So let us, yeah, one more thing. So our normal browsers won't direct to that port. So every browser has an option of setting a proxy from which it will redirect all the traffic. While creating a Firefox profile, we can set a proxy and in the proxy, I have given Inverse, IP address and port address. Once this is done, all the traffic, this driver, the object of this driver will run. It will be logged in Inverse. So this is how a typical Inverse test, integrated test look. We didn't do much change. In the start of the test, I called Inverse to tell that our workflow has started. So you start recording all the logs. Then I created my custom driver which would redirect all the traffic to Inverse. Then I did my particular steps which were earlier also there and in the end of the test case, I told Inverse, stop. This is my one flow. It has these many steps and these steps are a part of a workflow. We need to perform a workflow scanning on them. So let us see how this is done. Yes, you can run on the same machine. You can run on a different machine. We have given IP and a port number. So if you are on a network, you can have Inverse running on your remote machine and you can give the IP and port number of that machine and your tests are on your local. So you can run them. No, that is a thing. Inverse, it records everything and then we have to give it instruction that you start the workflow. If your, suppose your request has some 10 queries, 10 payloads, and every payload Inverse has to inject some 10,000 values. So 10 into 10,000, it is going to take some time. So your tests won't stop. The security scan would start, would continue in a, in back. So there are two different processes. They won't interfere with each other. They're using just the data. So you won't, it won't happen that your security scan stops so your functional test case would fail. It won't happen that you cannot run your functional test case again till the security scan is done. So there are two different processes running parallel together. So let us see how we run it. I'll show it to you. So I have, can everyone see? Is it visible? Okay. So this is a workflow which takes for DOM accesses. I start Inverse. I tell Inverse that my workflow has started. I create my custom driver. I have a wrapper class for Firefox browser with just, it creates a profile. It sets Inverse as the proxy and it returns the driver. So once I have the driver with Inverse configured, I perform my steps. So these are some of the steps which have been added. Then I quit the driver and I tell Inverse workflow has ended. Inverse has a feature which is workflow scanner. So here we'll see what logs are being recorded. I'll run the test case. I'll open workflow scanner. My browser has started. It has identified the IP. It has identified which logs, which logs are being recorded and then it also records the workflow name. So it is easier to identify that these logs belong to this workflow if we have given the name to it. After it has done, we do a scan workflow. So this is the time where all the payloads are injected into the query, into the headers and request parameters and this is the time where Inverse identifies all the security vulnerabilities. This takes like some time because a lot of payloads have to be injected. After this, a report is generated. A report, typical report, looks like this. So this report not only lists down the vulnerabilities found, it also tells for each vulnerability found, what was the vulnerability, what was the severity, what payloads were sent and how do we fix it. So it is very easy for the developers to fix the bug now if they've got so much insight into the vulnerability. It is very easy and it is very understandable. Anyone of us who doesn't know the jargons of security language can understand this report and fix it. So this is now we have converted a one test case into an Inverse integrated test case or you can say a security test case. Now most of us, we don't have just one test case. We have like thousands, 50,000, some of us have 50,000 test case. When we have a large repository of test case, we are definitely using some architecture or some framework to control them. Most commonly used is Java with test ng or junit. The best advantage with test ng and junit is you have these wrapper class, you have these annotations which control how the test case run. So what steps do we need to add into our existing test suite so that we can integrate it? First is creating a wrapper class for creating browsers so that it integrates Inverse. Next would be to create a base class which would call the start and the end function. If this base class before every test calls the start and the start Inverse and the end Inverse function, we don't need to add them to our test cases. And all the test case, if they inherit the base class, our work is done. And in the end a report is generated. Let us see how it is done. I have these two test cases redirects and accesses reflected. So they both don't have any Inverse calls. There is no start call. There is no end call in Inverse. Only the Firefox browser. I am using my wrapper of Firefox browser so that it is integrated with Inverse. If I have I have my suit file which includes both of these test cases and both of these test cases are inherited from the class base. Now my base class just has two functions. One is before class, it will call start Inverse and after class it will call end and sorry workflow end. If we have multiple test cases in a class, we can use before method functions or after method functions to record each an individual test case. When I run my suit file both of the logs both of the classes logs will be recorded in my workflow scanner. And I can do a security scan on them. So it is easy to implement if we have any framework. We don't need to do much case much changes to our existing framework also. So our our logs have been recorded and we can do a security scan on them. Why should we do this? Okay, we have got a tool. We have got some libraries. Why do we need to change our existing test cases? First thing is all of us cannot do a security check. Though we would like to do it is interesting and there are places where we've been questioned why didn't you check the security flaw? How would we do it? It is such a big topic. It is there is so much of knowledge needed to do a security scan. We just cannot. So instead of relying on others security audit, we can do it on our own. We have a scanner. We know how to integrate with our functional test case. We can do a security scan and we can come up with security bugs. There is no need for security pentesters to do it. Plus there are small organization who don't hire security people. Then they don't want to lose on to their product just because it has security flaws. They want their product to be strong and fix all the security bugs because security is one issue where everyone it is the highest priority issue right now these days. The next is we generate easily understandable reports. We don't need to be a security expert to understand the bugs and fix them. And another thing is testing is done during the middle of SGLC. If we find our security bugs over there, then later on we don't need to change some design architecture or any complications could arise later on. So very early in our SGLC we can fix the security issues. Before even going to site we can fix 60% of them and then we won't face so many security issues later on. And the biggest thing is if there are no security bugs on live then we don't have to pay ransom to bug bounty hunters. We can save a lot of money on that. But we still have some area of improvements on this integration part. The very first thing is speed and effectiveness. Current system actually replace each test case repeatedly which consumes lots of time and speed. Current system doesn't work properly for the Java script heavily based sites. If your website is really heavy this system actually slows down and as I mentioned before web applications are a little slower. Second thing is your coverage. So far, INVAS doesn't check vulnerability that client side. It tries to find your vulnerabilities at the server side. And as I mentioned before it will follow your functional test suit. It's nothing INVAS will take as the input whatever you mentioned in your Selenium test suit it will take input from your Selenium test suit. So in case in your application you are missing one feature for the automation okay I will not test this particular feature for the automation part. INVAS will not scan that particular feature because for that feature we don't have any input. So whatever we scan is based on the input you provide into your Selenium. Another thing is reporting. Whenever any bug is created generally we automate this bug into any bug tracker like Zira for Greek or Zoho bug tracker and anything. Currently we don't update these bugs into a bug tracker but yeah we are working on these things. So some parts in management that the INVAS app needs to be started before we run our test suit. It won't automatically start up as soon as it as tests are running. Sometimes the crawler crashes because the website is too heavy it's a very java script centric website. If a crawler crashes INVAS doesn't report it to us we have to manually find and restart the crawler. Then if a bug we found a bug using this system we fix it. Then the next time how do we verify the bug is fixed? INVAS doesn't give this functionality. We have to compare two reports whether a bug was found in report one or and if it's fixed it shouldn't be found in report two. We do not currently handle parallel functional test and request from multiple users. We are currently working on those features and INVAS doesn't automatically detect whether a workflow has started or ended. We need to specify calls to tell INVAS a workflow has started and ended. It doesn't automatically pick up this is the start this is the end and we need to set proxy INVAS doesn't listen on all ports it listens on only one port we need to set that and we need to make our browser compatible and configure our browser so that they send data to that port. Some of these features have already been fixed we'll soon be releasing them in our open source version and some of them we'll be releasing in our commercial version. As I mentioned before automated web scanners always doesn't fix all the problems because these are again tools made by human so if you come up to certain areas where these workflows are not perfect for you there are complicated bugs which are only found by the human because if you have any security bug into your business logic any security scanner cannot find it because any device cannot tell you that your business logic is wrong because it is following what you told him what you told him sorry so there are certain areas this automated web scanner is not perfect a human has to do certain security testing so yeah the best part is the business logic if you have any business logic kind of things you have to need you need a human intervention to find the applications bugs so what you can do in your company you can use this tool or any web scanners to find bugs on the periodic table regularly in fact but for such a kind of major bugs you need a security expert to find bugs into your web applications here are the references we used iron wasp and there's the library the library which integrates iron wasp is available at github it's an open source so anyone can contribute and we like to thank Lava Kumar who's the author of iron wasp and we we are done with our talk and we would like to take question and answers yeah whatever this tool will do whatever you are doing into your functional test so the curve exactly flow it will follow the same flow yes yes yes yes yes because in login we have a CSRF token generated and that needs to be unique we cannot use the same CSRF token every time so we need to do the same process again and again yes that is on our list actually we run everything every time a test case is done that was one of our limitations so we are improving on that we are we are going to a different measures on how to how to run the test how to record the logs we have pretty much covered that how to run scanning on them efficiently we are exploring different options we are generating an api for a lot of things like scanning might be one there might be you want to pause a test case you don't want to scan some part of a test case so pause and resume so most more calls of api are being generated and we are going to give them an open source no login selenium we are using to send data to iron wasp once iron wasp get all the logs it has a complete it has a complete request with the header and payload and what was sent in the header so using that data iron wasp does the logging selenium what is happening here whatever data you are using for from your selenium test case like including username and password iron wasp has logs so it tries to extract log as much data as possible from its logs to use for the security testing so we get this username and password from your functional testing logs we use security payloads from the iron wasp and we combine these two values and check for the security testing so selenium is just used to run your functional test if you want to use cilk you can go ahead with that if you want to use kocumber kocumber also uses selenium but if you want to use any other framework you are good to go ahead as long as your test case your test case runs on a particular port and ip which iron wasp listens to so we run on linux also and mac also no because there are some issues that some sites they don't allow proxies like if you go to google or lingden or pepal you want if your browser has a proxy set they won't run so those places our test cases would fail you cannot run on live sites but performance wise we didn't see any issues there have been some two three places where we've tried the system and they've been happy with the results okay so we'll be available here if anyone has any more questions thank you