Open Source InfoSec Using Gradle
Information security needs to be a part of any application. Solutions range in price from no cost to very expensive. However, quality is usually proportional to cost (but not always). We are going to look at no cost solutions that integrate with the Gradle build system.
Open Source Library Vulnerabilities
Libraries used in your application may have vulnerabilities that you don’t want to try finding yourself. There are third-party scanners that will inspect the binaries but these are expensive and time consuming. The CVE database is one publicly available database of vulnerabilities that can be leveraged to quickly identify offending libraries.
The OWASP Dependency Check plugin matches your dependencies against the National Vulnerability Database (NVD) hosted by NIST.
// build.gradle plugins { id "org.owasp.dependencycheck" version "4.0.0.1" } dependencyCheck { format='ALL' // the default is HTML only }
$ ./gradlew dependencyCheckAnalyze Generating report for project pet-store Found 175 vulnerabilities in project pet-store One or more dependencies were identified with known vulnerabilities: springloaded-1.2.8.RELEASE.jar: ids:(cpe:/a:springsource:spring_framework:1.2.8, org.springframework:springloaded:1.2.8.RELEASE) : CVE-2011-2730, CVE-2013-4152, CVE-2013-6429, CVE-2013-7315, CVE-2014-0054, CVE-2014-1904 scala-library-2.12.3.jar: ids:(org.scala-lang:scala-library:2.12.3, cpe:/a:scala-lang:scala:2.12.3) : CVE-2017-15288 ... $ ls -1 build/reports/dependency-check-* build/reports/dependency-check-report.csv build/reports/dependency-check-report.html build/reports/dependency-check-report.json build/reports/dependency-check-report.xml build/reports/dependency-check-vulnerability.html
In addition to the console output, it also produces a very nice HTML report and several machine readable formats.
Static Code Analysis with SonarQube CE
SonarQube scans source code for quality issues. One area of quality is vulnerability scanning. SonarQube has both commercial and community offerings. It does require a database and server running, but for small projects it can be run on the development machine. There are Docker images available that make it easy to manage.
// build.gradle plugins { id "org.sonarqube" version "2.6.2" }
# gradle.properties systemProp.sonar.host.url=http://127.0.0.1:9000 systemProp.sonar.login=abcdef0123456789
$ ./gradlew sonarqube
ZAP Dynamic Scanning
Dynamic scanning is attacking your application (in this case a web application) as it is running to find vulnerabilities. It’s the equivalent of end-to-end testing for security and as such the most expensive. The most thorough dynamic scanning is done by humans but tools can reveal quite a bit so it’s worth automating.
OWASP ZAP is an open source tool with an impressive API allowing automation. I improved upon a Gradle plugin to facilitate automation. My plugin source is at https://github.com/double16/zap-gradle-plugin, credit to https://github.com/PROSPricing/zap-gradle-plugin.
// build.gradle plugins { id 'com.patdouble.zap' version '2.0.2' } zapConfig { applicationUrl = "http://localhost:8080/" }
$ ./gradlew zapStart runApp zapSpider zapActiveScan zapStop $ ls -1 build/reports/zap zapReport.err.log zapReport.html zapReport.json zapReport.md zapReport.out.log zapReport.xml
The complexity of using this plugin varies with the application. It needs to know the URLs to scan which may or may not need authentication. You must code that authentication into the build script. As you add protections, such as CSRF tokens, you will need to account for that in authentication. The plugin source has examples for some popular vulnerable web applications.
Spidering starts at a known URL (such as http://localhost:8080 seen above) and visits links to try to get all the URLs of the application. This has various levels of success. If you’re using functional tests that drive a web browser, you can configure the web browser to use ZAP as a proxy and thereby populate ZAP with the list of URLs. The zapSpider
task won’t be needed and zapActiveScan
will use the URLs visited in the functional test.
You may also consider using this plugin to validate specific vulnerabilities or key areas and not spider and scan the whole application. Note that with all of the ZAP plugins installed, it can take a bit of time to scan the whole application.
Conclusion
Every application must be secured at some level. For application developers it can feel like a tax to be paid. Any pieces of the puzzle that can be automated will increase the quality of the code. As every user base and organization is different, be sure to carefully consider where automation fits into your security posture.
Happy coding!