Skip to main content

What is DAST, and Why Should Developers Use It?

 DAST stands for Dynamic Application Security Testing. DAST is the process of testing web, mobile, and API applications to find vulnerabilities/security bugs through simulated attacks.


DAST is the process of live testing an application either using an automated scanner or manual penetration testing practices.


Most developers haven't heard about DAST scanners because they are primarily used by appsec and penetration testers.


What kind of vulnerabilities does DAST find?

Most automated scanners would find critical vulnerabilities like SQL Injections, NoSQL Injections, XSS, etc. 

The hard-to-find vulnerabilities like logic bugs, authentication, and authorization flaws are usually done by ethical hackers, penetration testers, and AppSec engineers. The preferred approach is to write automated test cases that can be executed as part of CI/CD.


Should developers care about DAST? 

Yes, they should, since having any of the above critical vulnerabilities can lead to data breaches and punitive damages. Additionally, most DAST scanners can now be easily integrated into CI/CD pipelines, fully automated. 


Pros of DAST

  • Tech Stack Independent: Independent of the application stack. It tests the application as a whole. All your source code and libraries at runtime are tested for vulnerabilities.
  • It does not require access to the source code.
  • Low false positives: According to OWASP's benchmark project, DAST solutions produce fewer false positives than other testing approaches.
  • Identifies configuration issues: DAST excels at finding security vulnerabilities that occur only when the application is operational. In addition, DAST attacks an application from the outside in, placing it in the perfect position to find configuration mistakes missed by other AST tools.
  • Logic vulnerabilities: These flaws are hard to detect early in development. These issues are caused by security configurations, data, and other things, making them hard to detect in non-production environments. Most bug bounty programs pay for these kinds of flaws instead for traditional and low-hanging issues. Detecting these flaws requires you to write test cases and execute them continuously in dev/production.


Cons of DAST

  • Does not find the exact location of a vulnerability in the code
  • Tests can be time-consuming.



Here are a few free DAST solutions you can run safely against your live applications:


EthicalCheck:

Free & Automated DAST for APIs.

https://apisec-inc.github.io/pentest/


Burp Suite

Write your tests

https://portswigger.net/burp/communitydownload

Comments

Popular posts from this blog

Access multiple Databases in JPA

According to JPA specification we can define multiple "persistence-unit" elements (i.e. like below) in persistence.xml file and can easily refer them inside Dao layers as this. public class PolarDaoImpl {     @PersistenceContext(unitName="PolarPU")     protected EntityManager entityManager; -- } public class BearDaoImpl {     @PersistenceContext(unitName="BearPU")     protected EntityManager entityManager; -- } Checkout sample persistence.xml <?xml version="1.0" encoding="UTF-8"?> <persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">     <!-- Database 1 -->     <persistence-unit name="PolarPU" transaction-type="RESOURCE_LOCAL">         <

JPA 2 new feature @ElementCollection explained

@ElementCollection is new annotation introduced in JPA 2.0, This will help us get rid of One-Many and Many-One shitty syntax. Example 1: Stores list of Strings in an Entity @Entity public class Users implements Serializable {     private static final long serialVersionUID = 1L;     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;     @ElementCollection     private List<String> certifications = new ArrayList <String> ();     public Long getId() {         return id;     }     public void setId(Long id) {         this.id = id;     }     public List <String> getCertifications() {         return certifications;     }     public void setCertifications(List <String> certifications) {         this.certifications = certifications;     } .. }         Users u = new Users();         u.getCertifications().add("Sun Certified Java Programmer");         em.persist(u); Generated Tables    Users    Co

Reuse JPA Entities as DTO

Note : Major design advantages of JPA Entities are they can detached and used across tiers and networks and later can by merged. Checkout this new way of querying entities in JPA 2.0 String ql = " SELECT new prepclass2.Employee (e.firstname, e.lastname) FROM Employee e "; List<Employee> dtos = em.createQuery(ql).getResultList(); The above query loads all Employee entities but with subset of data i.e. firstname, lastname. Employee entity looks like this. @Entity @Table(name="emp") public class Employee implements Serializable {     private static final long serialVersionUID = 1L;     @Id     @GeneratedValue(strategy = GenerationType.AUTO)     private Long id;     @Column     private String firstname;     @Column     private String lastname;     @Column     private String username;     @Column     private String street;     @Column     private String city;     @Column     private String state;     @Column     private String zipc