Attacks to web applications is not a new threat variant. It has been around for the longest time, probably ever since the first websites went up en masse which was during the height of the Internet Bubble. Back then, anything and everything was registered with a .com, and even if you had a business plan that was even partially viable, you got VC funding right away.
Back then, the primary building frameworks for all of these web applications was that of ASP.NET, and Cold Fusion (from Adobe). There was also the standard HTML code as well that you could use.
But now, the advancements in web application has changed dramatically, where many software development teams now make use of such source code languages as PHP, Ruby on Rails, and the big one, Python. But with the pandemic of COVID19, attacks to these web applications have proliferated to the greatest levels ever yet.
This finding has been further substantiated by the recent study that was conducted by Tala Security. Their study is called the “Global Data at Risk – 2020 State of the Web Report”, and it can be downloaded at this link:
Almost 1,000 top and popular websites were audited for their various levels of security, and tests such as vulnerability to Magecart, formjacking, cross-site scripting (XSS), and credit card skimming as well as other threat variants were examined as well.
Here are some of the key takeaways of their study, as it relates to web application security:
*Web application security is declining, and has reached a new high since 2019, even despite the passage of the CCPA and GDRP, which impose huge financial penalties;
*On the websites that were surveyed, 92% of them use contact forms that are easily susceptible to what is known as “Formjacking”. This is the instance where you fill out a contact form, and from there, it can be intercepted by a malicious third party, in order to gain further access to your Personal Identifiable Information (PII). This includes such items as driver’s license numbers, credit card information, banking information, your location details, and such. While filling out a contact form is a normal process for a prospect to engage into inquiries, the attacks on this part of the web application has increased at least by 10X;
*The biggest threat variant that exists to web applications is what is known as “Cross Site Scripting”, or “XSS” for short. An alarming 97% of the websites that were audited are prone to suffering from a large-scale attack in this regard;
*What is even more alarming, some of the most trusted websites that were surveyed are at grave risk as well, and the pool that was surveyed, 99% of them have been technically whitelisted, but are still extremely vulnerable. One such example of this is Google Analytics
*Only 30% of the web applications examined had any sort of security protocols established from within their source code;
*Only 1.1% of the websites that were examined has any sort of effective security protocols embedded within it.
My Thoughts On This
Yes, these numbers are quite alarming. But if you dissect these findings, you will find some of themes in it, such as the following:
*It is even the so-called whitelisted domains that are also prone to attack on the client side, as previously described as well. This simply means that because a web application is deemed to be safe to use (that is why they are on a “whitelist” of sorts), they are still prone to Cyberattacks.
So what can be done to alleviate all of this? The answer is quite simple: Test, Test, and Test the source code of the web application before it is released to the client and goes into production mode onto their side. But this does not mean that the software development team waits until the very end when the project is completed in order to test the source code.
This must be done as each source code module is completed, and this process must be repeated in an iterative style fashion. By doing it this way, the software development team will not only be able to deliver the project to the client on time, but also, any security vulnerabilities that are found (especially those of backdoors) can be found and rectified in preceding source code module and stopped down in their tracks before it has a cascading effect onto other, subsequent source modules.
In this regard, probably one of the best methodologies that you can use is that of Penetration Testing.
With regards to the APIs, a bulk of them are available for download for free, because they make use of the Open Source concept. While this is certainly advantageous, it has one major pitfall: They are not tested by any means. The organizations that deliver these kinds of APIs usually leave it to the software development team to test the source code in them.
But very often, they do not, because they are under so much pressure to deliver on time and under budget for the client. The moral of the story here in this aspect: Always source code test the APIs before you implement them. You need to explain this to the client, and more than likely, they will greatly appreciate the extra time and efforts that you are taking, especially in today’s environment.
But despite the prevalence of the both the GDPR and the CCPA as well as the harsh financial penalties imposed, keep this other aspect in mind as well: If you deliver a web application to a client that has been hacked into, you will be held responsible for it, from both a legal and financial point of view.
Therefore, to avoid this, you should stipulate in your contracts with the client that you will not only test the source code before you release it to them, but that also they should conduct their own tests as well, and report any vulnerabilities back to you for correction. This should mitigate the risks of any potential legal actions that you could face down the road, as a result.