The web is the portal to business. It’s still true that the browser can talk to backend servers, but more and more applications use web protocols to connect to one another. These webs-of-applications form the basis for many information architectures today.
Application vulnerabilities can happen in all types of systems. For most developers today, web vulnerabilities are the most common. Application vulnerabilities have existed since the first web server permitted a user to provide input to a backend. In the early days these were generally related to input validation. That’s still true today.
The Open Web Application Security Project (OWASP) Foundation is a not-for-profit charitable organization behind the project, which collects information about web application security challenges and provides information about how to avoid them.
OWASP Top 10
- Top 10-2017 A1-Injection
- Top 10-2017 A10-Insufficient Logging & Monitoring
- Top 10-2017 A2-Broken Authentication
- Top 10-2017 A3-Sensitive Data Exposure
- Top 10-2017 A4-XML External Entities (XXE)
- Top 10-2017 A5-Broken Access Control
- Top 10-2017 A6-Security Misconfiguration
- Top 10-2017 A7-Cross-Site Scripting (XSS)
- Top 10-2017 A8-Insecure Deserialization
- Top 10-2017 A9-Using Components with Known Vulnerabilities
Each year since 2013 OWASP has published a “top 10” list of security vulnerability classes. These have evolved over the years as technologies have changed. What’s common to all 10 is that web application developers have a hand in preventing vulnerable code from going to production by applying secure coding techniques. You can, and should, read about the OWASP Top 10 at https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project.
One class of attack that has not changed since the foundation of OWASP is Injection. These occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.There are ways to prevent this, and OWASP publishes information about how to implement those best practices.
One of the valuable OWASP resources that developers can use is the collection of “cheat sheets.” Cheat sheets are short documents that describe actionable steps to avoid common vulnerabilities including injection. There are dozens of sheets that detail processes for specific use cases. You can find a master cheat sheet with pointers to others at https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series#tab=Master_Cheat_Sheet
OWASP is the most well known starting point to understand application vulnerabilities and how to avoid them. It would follow that many books and training courses have been written that follow OWASP as an outline.
Two training resources available on campus are SANS training and LinkedIn Learning (formerly Lynda.com). The Office of the CIO procures a limited number of seats for SANS Developer training. Contact the Chief Information Security Officer for availability of seats. The SANS course is approximately 3 hours of computer based training that covers the OWASP top 10 as well as other topics like version control and testing. Lynda.com offers several classes in secure software development. These are available at no cost to campus staff members. You can link to Lynda.com through the UCSB Learning Center. Search for “secure software development.”
Testing and quality control are part of any well managed software development project. There are tools available to help test web applications for many of the vulnerabilities in the OWASP top 10. The campus already gets the benefit of some public services, such as Dorkbot from the University of Texas, which automatically and periodically scans for injection vulnerabilities. If any are discovered, the UCSB Security Operations Center (SOC) will notify the security contact for the network segment where the server is located.
Application developers should consider other tools and methods to test during the development and release processes. OWASP publishes a testing guide. There are many open source and commercial tools that are available.
The SOC maintains a license for NetSparker. Development teams can request a scan of a complete application in a dev/test network by contacting the SOC (firstname.lastname@example.org). These tests can take hours to days to complete depending on the complexity of the application. These tests should be run prior to move-to-production, however they are not suitable for iterative tests during development.
Development teams should consider fully implementing open source tools lor licensing one of the many available cloud or on-premise testing tools available. The OWASP testing guide has a directory of tools at https://www.owasp.org/index.php/Appendix_A:_Testing_Tools.