Web frameworks are a useful tool to many application developers. They automate the application development process, provide access to libraries and databases, offer reusable templates, and facilitate quick web application deployment to the internet. Once deployed, the web applications often support unique and critical website functionality, such as capturing end-user inputs, doing calculations, or enabling shopping cart functionality on ecommerce sites. Web frameworks are a standard tool in today’s web application development process, particularly on the client side.
Unfortunately, the third-party code found in client-side web frameworks can also be inherently dangerous, for three reasons:
- As much as 70% of web application code used in web frameworks is sourced from third parties, which means the organization using the third-party script has little visibility into the script or control over script safety.
- Third-party scripts can behave differently on different websites.
#2—Lack of Visibility Into and Control Over Third-Party Code
In today’s fast-churn, web application development environment, few businesses rely on applications created wholly in house. Instead, businesses turn to web frameworks containing code developed by other parties. This code could be written by the framework developer, it could be purchased from a third-party vendor source, or it could be obtained from open-source libraries like GitHub.
Few businesses have full visibility into or control over the third-party code contained in web frameworks. This may be due to lack of adequate internal staffing to review the code, or it could be due to the organization not having visibility into code updates instituted by the third-party vendor that created the code. Either way, if the web framework developer or third-party vendor was sloppy in their code creation or if the script contains intentionally malicious code, then the organization using the script may suddenly find itself the victim of a client-side attack.
#3—Third-Party Code Can Behave Differently
Third-party script activity can vary, depending on how script behaviors have been implemented within a framework. For example, on one website, a script may initiate various network activities or access certain input values, while on other websites the script may act entirely differently. This makes it impossible to trust a third-party script based solely on how the script operates on another website. Website owners often have very little visibility into how the web framework developer implemented certain script behaviors.
Vulnerable or malicious client-side web application code can facilitate any number of web application attacks, including:
- Cross-site scripting (XSS)
- Web skimming or e-skimming
- SQL injections
- Ad injections
- Denial-of-service (DoS) attacks
- Data exfiltration or compromise of sensitive organizational or customer data
- Watering hole attacks (attacking users that visit your website)
What is the Impact of a Web Application Attack?
Customer data loss and business reputation are the two big impacts associated with cyberattacks on a web application. Credit data and sensitive personally identifiable information (PII), like birth dates and social security numbers, combined with names can be sold on the dark web for a tidy profit. In addition, regulatory fines related to failure to notice or stop website attacks and breaches can also impact the business. Finally, unprotected websites that have suspicious code or malware embedded in them can result in Google Blacklisting, in which Google lists the website as ‘suspicious’ and displays a message to the user which says: “This site may harm your computer.”