The Top 4 Mistakes Made By Software Developers: Perspectives From A Penetration Tester

 

For quite some time, in fact going into last year, I have written quite a bit in these blogs about the importance of secure source code, especially when it comes to creating Web based applications.  For the longest time, software developers have evaded the Cyber scrutiny.  But now, with everything being remote and digital, the light is on them now to test their code before they send it off to the production environment. 

There is no doubt that the software developer of today is under a lot of strain and pressure to get projects out to clients under budget (if possible), but most importantly, on time.  Thus, security always takes a back seat.  If there is any kind of checking done, it is usually done at the end of the SDLC, when there is really not a lot time to do rigorous testing of the source code.

In order to drive home the importance of this topic, I came across an article in which a Penetration Tester describes how he still sees mistakes being made in the compilation of the source code, and what the vulnerabilities are as a result.  Here is what he has found, so far:

1)     Cross Site Scripting still exists:

The acronym for this is known as “XSS”.  According to the OWASP, it can be technically defined as follows:

               “It is a type of injection, in which malicious scripts are injected into otherwise benign and        trusted websites. XSS attacks occur when an attacker uses a web application to send malicious            code, generally in the form of a browser side script, to a different end user. Flaws that allow               these attacks to succeed are quite widespread and occur anywhere a web application uses input       from a user within the output it generates without validating or encoding it.”

               (SOURCE:  https://owasp.org/www-community/attacks/xss/)

               Simply put, this is where a Cyberattacker injects a piece of malicious code into a backdoor (or      another vulnerability) of the Web application.  The idea here is to gain control of the application             in question, and from there, try to hijack information and data as possible.  A very common             example of this are what are known as “SQL Injection” based attacks, where the hacker will   inject malicious queries into a SQL databased (such as SQL Server, MySQL, etc.).  More         information about XSS attacks can be seen at this link:

               https://www.darkreading.com/attacks-breaches/xss-flaw-prevalent-media-imaging-tool-      exposes-trove-patient-data

2)     Vulnerability scans may not be enough:

If any check on the source code is done, it is usually conducted by a Vulnerability Scan.  This kind of test is a good one to conduct, but it does suffer from a number of pitfalls.  Probably the biggest one is that it is not comprehensive enough.  For example, it is only considered to be passive in nature, and will only find those gaps that are blatantly obvious.  It will not go to the extent and detail that a Penetration Test would.  Thus, as I have always said, software developers should always test the source code on a modular basis, so that any unknown vulnerabilities will not have a cascading effect onto the rest of the source code.  If possible, it would be very prudent to conduct a Penetration Test at each level.  To help do this, there are tools out there that can automate this process.  But in the end, human involvement is always necessary to confirm any findings.

3)     Need to think outside of the box:

Software developers are tasked to do one thing only, and do it the best that they can:  Create the source code so that it meets every need and requirement of the client.  And if they can come up with some extra features that would benefit the client, that is a nice to have also.  In other words, the main focus of the software developer is on meeting the business objectives of the project.  They are not tasked with taking the flip side of the equation, which is seeing how the source code could be used maliciously by a Cyberattacker.  But this is not the same as testing.  Rather, the software developer is trying to take the mind of the hacker, and figuring out how the code can be further exploited.  But in the end, it is not fair to ask the software developers to do this herculean task, and probably many of them do not have the mindset to do this.  Because of this, many businesses in Corporate America are now turning to what is known as “DevSecOps”. This is a fancy piece of techno jargon which simply means that along with the software developer team, the operations and the IT Security teams are also involved in the development of the Web application project in order to lend a helping hand to make sure the source code is tested and secure.

4)     Everything is fair game:

When developing the source code, software developers often rely upon APIs.  These are reusable lines of code that are used to bridge the gap between the front and backends of a Web based application.  Any software developer can download these from open sourced libraries, but the problem here is that these API libraries are often not tested or upgraded with the latest patches.  Very often, the software developer thinks that this is not their responsibility, but the bottom line is yes, it is!!!  Ideally, it should be up to the owner or organizers of the API repository to check for all of this, but the ultimate accountability comes down to the person that is going to use and implement those lines of code. This is another area where the DevSecOps concept is becoming quite important, and will be so for a long time to come.

My Thoughts On This:

In a way, I am glad to see that software developers are going to have be more accountable for the code that they create and execute.  But in the end, they should not have to shoulder all of the responsibility, it takes the entire company to make sure that a Web based application is safe and secure to the client.  To use the old saying, “It takes a village”. 

But, there is one area in which software developers have to be completely, 100% responsible for:  It is in the backdoors that they create.  For example, rather than having to go through the usual login process that they create for the application, the software developers will create easy access portals in order to gain quick access to the source code.

But very often, right at the end of the project, they forget to check for these backdoors that they have created.  As a result, this is one of the first areas that a Cyberattacker will scope out for, and try to penetrate into first.