burpsuite – Cyber Security Kings

Choosing a Dynamic Application Security Testing (DAST) tool requires careful consideration, as not all DAST tools are equal. In the following article, I'll take a look at a few points I normally use in my evaluation criteria. Which Tool Is Used For DAST? Choosing the correct tool for Dynamic Application Security Testing (DAST) will ensure vulnerabilities and security issues like the OWASP Top 10 are detected in websites and APIs quickly before they can be abused by hackers. Popular DAST tools include the following: Rapid7 AppSpiderVeracode Dynamic AnalysisAcunetixRapid7 InsightAppSecSynopsis DASTFortify WebInspectBurpSuiteOWASP Zap In the rest of this article, we'll take a look at the DAST tools mentioned in the list above and what criteria needs to be considered when it comes to choosing the right DAST tool. 1. Rapid7 AppSpider AppSpider from Rapid 7 provides dynamic security testing of web and mobile applications, scanning for vulnerabilities and security issues. 2. Veracode Dynamic Analysis Veracode's Dynamic Analysis is a DAST tool capable of providing vulnerability, configuration and security issues in web applications. Provided as a SAST tool, Veracode Dynamic Analysis comes as a fully managed service, requiring little configuration and set up. 3. Acunetix Acunetix provides a suite of applications to security test web applications such as dynamic websites. Using tools like AcuSensor and it's vulnerability scanner, real-time detection of website vulnerabilities and issues can be pinpointed. 4. Rapid7 InsightAppSec Another tool from Rapid7, InsightAppSec provides rapid scanning of websites and API for security issues in real-time. 5. Synopsis DAST Synopsys provides a managed DAST service with scale to deal with large assessments of vulnerabilities and security issues in web applications. 6. Fortify WebInspect Fortify WebInspect from MicroFocus provides dynamic web scanning with automatic dynamic security testing for vulnerabilities and issues in web applications. 7. BurpSuite Burpsuite's Web Vulnerability scanner is designed to quickly determine vulnerabilities and security issues in web applications by using a number of tools. 8. OWASP Zap OWASP ZAP is an open-source web application testing tool providing passive and active testing of websites and web applications. What is DAST? Dynamic Application Security Testing (DAST) is a set of tools used to automate the security testing of the application by looking for security vulnerabilities in the running state of web applications and APIs. The DAST tool discovers security weaknesses by using a library of attacks to see which ones the application doesn’t protect against. DAST is important for Application Security (AppSec) to find security issues with custom-developed applications. Unlike vulnerabilities in vendor software where the vendor needs to come up with a fix, AppSec is the responsibility of the organisation developing software. If the organisation's developers or third party developers make mistakes, this leaves the organisation vulnerable. These vulnerabilities are classed as Critical Weakness Enumerations (CWE) as they are not yet discovered by anyone else outside of the organisation testing it's applications. CWEs require the organisation developing its application to come up with a fix for these security weaknesses. Whilst vulnerabilities in vendor software are classed by Common Vulnerabilities and Exposures (CVE). DAST Tool Requirements When picking the right DAST tool, it is important to use a set of requirements to make sure correct decision is made. These requirements will allow an informed judgement to be made to ensure the DAST tool selected is appropriate for your organization. To find the right DAST tool for your environment, a thorough investigation is required using the following criteria: Coverage Attack types Automation Performance Security Placement Mobile Application Security Integration Compliance Standards A SAST tool is part of the whole security profile of development and deployment of code, other security elements like SAST, container security scanning and RASP need to be considered too. I'm not going to recommend any DAST tool, as most do a good job and one brand of DAST tool might be right for one organisation but may not right for another. However, I will look at the considerations required for choosing a DAST tool, as detailed below. 1. Coverage Coverage is a very important aspect of the consideration of a DAST tool. The DAST tool needs to be able to interact in the same way as a user or service would interact and more. It's imperative these interactions are accurate and concise to be able to get the most benefit out of the DAST tool. Without the correct interaction being observed will lead to low visibility of potential security issues, leaving a plethora of blind spots. These blind spots are ripe for exploitation, putting the application and ultimately the organisation at risk. Closed and Open networks DAST tools need to be able to work in closed networks, that is within the internal network, so the tool can be used as part of the development lifecycle. As well as externally, that is outside the organisation's network, allowing the application to be tested in the same way a customer or service would interact with the application. APIs Applications composed of APIs can become problematic to test if the DAST tool is not capable of determining all of the APIs are present, as this will lead to untested APIs. Untested APIs are blind spots open for exploitation. Well documented APIs will be easier to determine, especially if they've been done using tools like Swagger or with YAML files. This will make it easier for API discovery, so it's imperative that good practice is in place during the development APIs to document APIs being developed. In some of the open-source tools I have used, the ability to determine documented APIs has been non-existent and a manual mapping exercise was required. Leaving room for human error and potentially missing out on some of the APIs. Sitemaps I always try to find out how the DAST tool will do the discovery of web pages when there's no sitemap to work from. Whilst having a sitemap makes it easier for discovery, if a web page is missed from the site map, how can I be sure the DAST tool has been able to find it and more importantly test it? Relying on a sitemap as the source of truth for your web pages may help in Search Engine Optimisation (SEO) and getting more of your web pages indexed but in dynamic testing, it shouldn't be relied upon as gospel. The DAST tool must be able to find web pages without having to just rely on a sitemap. Modern Web Frameworks With many modern frameworks being used in the development of front end web applications such as Vue, Angular, React and so on, the DAST tool needs to be able to work with these frameworks in a manner that allows it to determine security issues. The last thing I would want with a DAST tool is to find an inability to provide full coverage of the web framework being used. 2. Attack types The DAST tool needs to be able to do Passive Attacks as well as Active Attacks. Passive Attacks Passive attacks are used by hackers to gain information to use in running an attack at a later time. Passive attacks could involve looking for potential security exploitations in a web application by running various tests to check for open ports, vulnerabilities to misconfigurations. Or maybe the passive attack is only concerned with trying to find valuable information on a website, that has been left there by mistake. One of the frameworks I use for development if not properly configured can expose sensitive credentials when the website is deployed. By using a simple Google search, many hackers can find websites which have been incorrectly configured and can see the environment variables. These environment variables give away details of the database names, database usernames, database passwords, SMTP Email usernames and passwords. Hackers are running passive attacks to find information like this and when they act on this information, they log into the database and email servers using the credentials they have found, they are doing an active attack. Other passive attacks include gaining valuable information about websites where due to a misconfiguration, debug information is displayed because the debugging which should be disabled in production environments, has been left on. This presents a treasure trove of information to the would-be hacker. For the DAST tool selection process, some form of passive attack detection is important, especially if the DAST tool can pick up on security issues such as the ones highlighted above. Active Attacks Once the information has been gained from a passive attack, the hacker will try to exploit the information and use it to attack the application. By determining which passive attacks the application under test has left itself open to, the application can be updated to close down this treasure trove of information getting out into the open. A good DAST tool also needs to have an arsenal of active attacks in its armoury to quickly determine the security posture of an application. From being able to brute force authentication systems to entering incorrect data types to check validation capabilities. Attack Intelligence The DAST tool is only as good as the attack intelligence it's supplied with by its vendor. This attack intelligence comes in the form of attack policies applied by the DAST tool on the application under test. Vendors with poor attack policies will cause their DAST tools missing out on coverage, raising the risk of security issues creeping into production or if it's a production on-going test, then leaving the security issue wide open. 3. Automation DAST tools need to have a high degree of automation to ensure that manual intervention is minimised. A DAST tool ideally needs to have a good set of automated attacks that can be run to simulate the many threats a typical application will be exposed to. What is the benefit of running a DAST automated test? By using automated attacks as much as possible makes the running of the DAST tool more cost-effective, as automated attacks don't require human intervention, thereby making them cheaper to run. There will probably be some attacks which can't be automated and these manual attacks will require a deep-dive approach. Where specialist skills can be used and if need be specialists brought in, however as the large majority of attacks will be automated, the cost of bringing in specialists will be far more appetising. Scheduling Being able to run automated DAST scans at a time to suit is important in the selection criteria. As the DAST scanning may be done on a production 'live' application and it may be prudent to do the scans when the application is not being used overly. Doing DAST scans out of hours isn't as easy as it seems, especially if the application has global usage. So an understanding of expected usage patterns can help in determining the best time to schedule a DAST scan. 4. Performance It's important to ensure any DAST tool under evaluation doesn't hinder the development process by slowing it down. As the DAST tool will ideally be incorporated in the CI/CD pipeline, any adverse effects on the time taken to run the automated attacks, gather analysis and report back on the analysis will affect the CI/CD pipelines ability to get the application ready for deployment. There's little point in selecting a DAST tool that takes several hours to run automated attacks. As the delays in getting the analysis back impact the time to also remediate the code and then regression test it all again.It's imperative the DAST tool doesn't become the major bottleneck in developing applications. Multiple tests There may be a need to run multiple DAST attack tests, at the same time especially if there are different product teams working on different deliverables. Any DAST tool chosen needs multi-tasking capability, that is the capability to work with multiple pipelines if possible. Otherwise, there's going to be a slow down in delivery, as different teams applications will end up in a queue waiting for another development teams application to be analysed by the DAST security tool. The DAST tool must not become a bottleneck and impact delivery and performance 5. Security The security of the DAST tool itself is important as the tool may not be 'self-hosted' in the organisation's own environment. Many DAST tools these days are being provided as a vendor managed service in the form of a Software as a Service (SaaS) delivery. SaaS security SaaS reduces the DAST systems required in the customer's environment with the vendor responsible for the security of the DAST components that live outside the customer's environment, that is in their SaaS environment. This creates security considerations requiring immediate attention when the application being tested is of high integrity and high-security nature. The implications of this sensitive information being sent externally to a vendor and their DAST SaaS systems for analysis will definitely require some form of risk assessment, along with the security posture of the vendor and their overall SaaS-based DAST solution. Authenticated scans As part of the real-life attack scenarios to be played out by the DAST tool, some will involve checking areas of the web application which required authenticated access. The DAST tool under test must be able to integrate with any authentication scheme in a secure manner, ideally without having to store hard-coded secrets itself. Secrets I normally check how the DAST tool handles secrets, as it will probably need some form of secrets to do authenticated scans. Whilst with a 'self-hosted' DAST tool in a data centre or within an organisation's public cloud account, the security risk of the communications is lower (still highly recommend this needs to be secured) for credentials used. Does the SaaS DAST tool handle secrets securely? For SaaS connections to DAST services where credentials leave the network boundaries and cross over public transport, the internet, it's essential all communication has sufficient security controls around them, such as identification, authorisation to encryption. Sending credentials across public networks such as the internet without any form of encryption or authentication or authorisation spells trouble. Roles Roles are an important consideration in separating out privileged and non-privileged access to a DAST tool. As privileged access to manage and administer the DAST tool shouldn't necessarily be used to run the scans or be given to all users using the DAST tool. 6. Placement The placement of the DAST tool is an important consideration for evaluation as to how the DAST tool operates influences this. Having a "Shift left security" placement will allow applications to be tested by the developers, allowing security issues to be found during the development stage and be quickly remediated at less cost than if they are found later on in production type environments. Does the DAST tool have extensions to allow developers to test their code? Being able to run dynamic tests in a development environment before any code is pushed into the CI/CD pipeline can help developers reduce any dynamic security issues. Some DAST tools have extensions that can be added to web browsers, allowing functionality to be tested by recording actions. This could allow attacks to be played on the application to look for Critical Weakness Enumerations (CWE), that is security issues. CI/CD Pipeline The DAST tool must be able to work as part of the CI/CD Pipeline whereas code is pushed into the pipeline and built into an image the final checks should be the DAST checks to see if there are no weaknesses in the final build that can be attacked and exploited. Placement as part of the CI/CD pipeline is fine for new releases of applications that come through the pipeline. However, this doesn't mean that's the end of the road for the DAST tools involvement, far from fit. Post 'Live' The DAST tool needs to regularly check on applications after they have been released that is, post 'Live' to see if something new hasn't appeared. This could be a new type of attack or a misconfiguration whilst routine maintenance causing an issue, such as directory permissions changed inadvertently giving the public access to private areas where configuration information is held. People make mistakes, especially when they are rushed into making changes and it's always good to have a DAST tool that can pick up on this. Acting on what the DAST picks up is another matter as this will be wholly dependent on whoever receives the reports generated by the DAST tool. Internal vs External scans Many organisations will do internal DAST scans on a version of their application that is in a pre-stage environment. This pre-staged application is identical to their production application, so the assumption is that any issues in the pre-staged application will also exist in the production externally facing application. Internal scans won't affect the performance of the production version of the application as this is not scanned. Internal scans can also fall into the remit of SOC Red Teams, allowing them to keep an eye on any security issues. Other organisations will do external scans where the DAST tool is able to run tests on the actual public-facing application and generally schedule this to run at a time when there will be the least impact on the application. Any DAST tool must be transparent in its operation, that is, it doesn't impact or slow down markedly any services it is being used to test. Any DAST Tool being selected needs to work for the organisations choice of scanning be it internal, external scanning or a combination of both. Internal scanning needs to be able to access the application in the same way as the external scan would, that could be using the same identities for authenticated scans. This could be an issue if the identity provider is only available externally, as opening communication ports could introduce an additional security risk. Finding out from the DAST tool vendor how scans are supported externally, ideally through a SaaS version of their product is highly recommended, along with an understanding of the security implications of using a SaaS version. Running a DAST scan on production services needs to be carefully assessed prior to use. Including how any alerts will be assessed and remediated. Blocking a service from running if exploitation is found in it, might not be an option as this could stop business services from working and cost the organisation lost revenue. 7. Mobile Application Security Assessing the capability of the DAST tool to test mobile applications is part of the assessment I will always do when reviewing DAST tools, even though in the current scope of work, developing a mobile application may not be in the organisation's plans. It's important to appreciate that testing the security of just the web application doesn't necessarily reduce the attack surface as side-channel attacks against other flavours of application can still take place. So developing a mobile application alongside the web application requires both to come under the remit of DAST testing. The DAST tool needs to be able to effectively test applications being developed for mobile devices such as Android and Apple devices, to ensure the overall attack surface is minimised against potential hackers. Security testing doesn't just look at any security holes in the mobile application but how the mobile application communicates with the back-end services, it needs to be able to provide functionality expected. Any weakness in the communication not only puts the mobile application at risk but exposes the whole application stack from the web application, back-end and mobile application at risk of exploitation through a single side channel. As a footnote to mobile application security, it's vital the same security posture is adopted as developing any other type of application with a Secure SDLC applied. 8. Integration Integration is an important consideration in the DAST tool selection process, as it allows organisations to get the full benefits of using the DAST tool. Continuous Integration Integration into a CI/CD pipeline is a given and this could be through automation services such as Jenkins, so it's best to check if the DAST tool vendor provides a plugin or failing that there's a plugin available from the community. A word of warning, make sure the plugin doesn't have any vulnerabilities, as, from experience, a DAST tool I was assessing had a plugin which kept the DAST credentials in clear text, allowing anyone to access the DAST tool if they got hold of credentials from the plugin. Some pipelines may not have integrations available, such as AWS CodePipeline, so some form of configuration may be required in these pipelines to be able to use the DAST tool. SIEM Integration DAST tools will generate logs and alerts and these need to be collected centrally for analysis, should certain events be deemed actionable. A Security Event & Incident Management (SIEM) service could provide this. At a basic level, audit logs must be collectable to determine who or what (service) has used to DAST tool from a forensic point of view. A SIEM integration is essential in keeping abreast of any insider threats. Having a Security Operations Centre (SOC) Red team run external DAST scans is a good way of limiting insider threats from development and infrastructure teams. Ticket Integration Ticket Integration with systems like Jira is a nice to have feature, as this will reduce the time for notification of any vulnerabilities, allowing developers and system engineers to quickly become aware of what needs to be remediated. WAF Integration The ability to integrate with a Web Application Firewall (WAF) is essential as this will allow the WAF to block attacks to security vulnerabilities picked up by the DAST tool that is in the process of being fixed. IPS Integration Intruder Prevention Systems (IPS) integration is a nice to have feature, where the IPS such as a Next-Generation Firewall can block attacks to security vulnerabilities, for example, a vulnerability with the Secure File Transfer Protocol (SFTP) could be blocked at port 22 until the SFTP can be patched. 9. Compliance Standards Many organisations are either regulated or have to work to varying degrees of compliance and a DAST tool should be able to provide templates to facilitate compliance assessment. An organisation developing payment software requiring PCI DSS compliance would benefit from PCI DSS compliance checking available in the DAST tool. DAST Vendor Compliance At a minimum, I would look at whether the DAST Vendor is SOC2 compliant as this provides some basic assurance they have been assessed to a standard. Using a SaaS service needs careful consideration, as the vendor's SaaS is doing the analysis by the vendor's system and this might not sit well with people higher up in an organisation. The risks will need to be understood and some form of third party assurance will need to be definitely done. Is DAST a Silver Bullet? Finally, DAST tools should not be considered to provide an almost 'holy grail' level of security testing but they only consider what's been tested and not the testing of how what's been tested fits into its ecosystem. So a web application pencilled in to be deployed on Amazon Web Services (AWS) needs to have its AWS configuration tested. There's no point in patting yourself on your back to delivering an application that the DAST tool says has no security issues when the web application stores sensitive data in a public S3 bucket. DAST testing is front end testing and when complemented with back end testing, affects the overall security posture. Any web application being developed will have a back end (infrastructure, databases, caches, queues, API gateways) and it's this back end that also needs to be tested to make sure it's secure. This is why I always advocate a full PEN test (across the stack) as a requirement for any new application releases with further PEN tests for any major changes in functionality. Giving assurance the back end is secure as well as the front end application. So why have a DAST tool if PEN testing is still being done? The DAST tool should never be thought of as a replacement for the PEN test activities. Instead, it should be viewed as a form of continuous compliance to make sure: the application is ready for a PEN test as part of a successful CI/CD pipeline delivery;any changes in attack and any misconfiguration post 'live' are uncovered by the DAST tool checking;minor changes where there is not a major change in functionality where a PEN test would be prohibitively expensive, are still checked for security issues. The last point still meets the goal of a rapid release cycle, as many releases are simple fixes and changes. Some organisations may have a different view on risk and decide the PEN test only happens at the first release and any subsequent release is good to go if the DAST tool doesn't come up with any show stoppers. Or maybe no PEN test is done and the DAST tool is all that's used as proof of an application ready for go-live. Related Questions: What is SAST? Static application security testing (SAST) is the process of analysing application source code, binaries (also known as compiled code or byte code) for security vulnerabilities. The approach taken is static, that is the code analysis is done in a non-running state where the code is at rest and not in use. What tools should a DAST tools list contain? A DAST tools list will contain Rapid7 AppSpider, Veracode Dynamic Analysis, CheckMarx, Acunetix, Rapid7 InsightAppSec, Synopsis DAST, MicroFocus, BurpSuite and OWASP ZAP. Disclaimer: I am in no way affiliated with, or endorsed or work for any of the organisations mentioned in this article.