Writing (In)Secure Code

Leontin BîrsanSolution Architect

Thursday 13 April 2023

VERSION 2.0

Software’s Vulnerability to Attack

• What makes it so easy for attackers to target software is the virtually guaranteed presence of vulnerabilities, which can be exploited to violate one or more of the software’s security properties

• Most successful attacks result from targeting and exploiting known, non-patched software vulnerabilities and insecure software configurations, many of which are introduced during design and code

• Many successful attacks result from poor coding which open the applications vulnerable to SQL injection, buffer overflows etc.

When Is There a Threat?

The software’s security can be threatened:

• during its development:– A developer may corrupt the software (intentionally or

unintentionally) in ways that will compromise the software’s dependability and trustworthiness when it is operational.

When Is There a Threat? (2)

The software’s security can be threatened:

• during its deployment (distribution and installation):– If those responsible for distributing the software fail to

tamperproof the software before shipping or uploading, or transmit it over easily intercepted communications channels, they leave the software vulnerable to intentional or unintentional corruption.

– Similarly, if the software’s installer fails to “lock down” the host platform, or configures the software insecurely, the software is left vulnerable to access by attackers.

When Is There a Threat? (3)

The software’s security can be threatened:

• during its operation:– Once software has gone operational, vulnerabilities may be

discovered and publicized; unless security patches and updates are applied and newer supported versions (from which the root causes of vulnerabilities have been eliminated) are adopted, such software will become increasingly vulnerable.

– Any software system that runs on a network-connected platform has its vulnerabilities exposed during its operation. The level of exposure will vary depending on whether the network is public or private, Internet-connected or not, and whether the software’s environment has been configured to minimize its exposure.

– But even in highly controlled networks and “locked down” environments, the software may be threatened by malicious insiders (users, administrators, etc.).

When Is There a Threat? (4)

The software’s security can be threatened:

• during its maintenance:– If those responsible for addressing discovered

vulnerabilities in released software fail to issue patches or updates in a timely manner, or fail to seek out and eliminate the root causes of the vulnerabilities to prevent their perpetuation in future releases of the software, the software will become increasingly vulnerable to threats over time.

– Also, the software’s maintainer may prove to be a malicious insider, and may embed malicious code, exploitable flaws, etc., in updated versions of the code.

The Challenge of Building Secure Software

• To be considered secure, software must exhibit three properties:– Dependability: Dependable software executes

predictably and operates correctly under all conditions, including hostile conditions, including when the software comes under attack or runs on a malicious host.

– Trustworthiness: Trustworthy software contains few (if any) vulnerabilities or weaknesses that can be intentionally exploited to subvert or sabotage the software’s dependability. In addition, to be considered trustworthy, the software must contain no malicious logic that causes it to behave in a malicious manner.

The Challenge of Building Secure Software (2)

• To be considered secure, software must exhibit three properties:– Survivability (also referred to as “Resilience”):

Survivable (or resilient) software is software that is resilient enough to

• (1) either resist (i.e., protect itself against) or tolerate (i.e., continue operating dependably in spite of) most known attacks plus as many novel attacks as possible, and

• (2) recover as quickly as possible, and with as little damage as possible, from those attacks that it can neither resist nor tolerate.

Practical Example

How To Protect Code

In two words: Defensive Coding.

1. Never trust the user input and I do mean NEVER– Trusting user input is a generally bad idea, as seen in

the examples we do open the application to various attacks

– User input should be sanitized and validated, if not done automatically by the framework (e.g. ASP.NET MVC)

– Always perform basic tests over the input, such as length and range

How To Protect Code (2)

2. Do not relay solely on client-side validation, re-validate always on server-side

– Validating only on client side does not protect against call injection which will bypass the protection

– JavaScript can be disabled in the browser options disabling the validation

– Use framework built-in validation, e.g. for ASP.MVC use data annotations such as [Required], [StringLength(10)], [Range(10, 20)] etc. which will fire automatically on each request, then use subsequently ModelState.IsValid to check the validity of the request

How To Protect Code (3)

3. Never build SQL by means of concatenating strings that contain user input. Always use parameters.

– In general, building SQLs with “+” is a really bad idea– However, in some cases, dynamic SQL must be built,

but it should not contain any user-generated content– If dynamic SQL is to be created use a factory method or

class to contain the respective code in one place– Such code must be reviewed for possible security issues

How To Protect Code (4)

4. Test parameters of the functions– Test for NULL and allowed ranges and throw exceptions

if the validation fails– If unit tests are built, test for the respective exceptions by

passing intentionally incorrect parameters and expecting the exceptions

5. Prevent errors– If an error is possible, no matter how probable, try to

prevent it

6. Fail Early And Openly– Fail early, cleanly, and openly, stating what happened,

where and how to fix it

How To Protect Code (5)

7. Document Assumptions– Clearly state the pre-conditions, post-conditions, and

invariants

8. Avoid Over Documentation– Do not do documentation that can be done with code or

avoided completely– Code is the best documentation– Always document hard to understand parts

9. Simplify And Clarify– Always simplify the code to the smallest, cleanest form

that works without sacrificing safety– Keep methods to one task only, delegate subtasks to

other methods

How To Protect Code (6)

10. Use static code analysis– Run tools such as FxCop and StyleCop to analyze the

code and react to all received warnings• FxCop warnings are over 90% of the time correct and

therefore they must be addressed

• StyleCop warnings are tailored for a different set of coding standards than the one used internally and must be twaked

11. Unit test the code– Regardless of Test Driven Development (TDD) or After

Development Testing (ADT) strategy used, when possible create unit tests as they:

• help on finding bugs early

• help on regression testing

How To Protect Data

• Encrypt passwords with a strong, salted, one-way hash such as SHA-512

• Encrypt sensitive data with AES-256 or even better with an asymmetrical algorithm

• Use database-level encryption if possible• Use secured storage for files, do not store files

under the web application root, always use an external folder properly configured to allow access to required users only

• Transfer sensitive data over secured connections (e.g. use HTTPS instead of HTTP)

• Do not invent security algorithms, stick to standards

Other Protection Methods

• Log everything, although this does not protect anything, can help detect issues and break-ins and it also helps debug the application

• Avoid using the disk. Do not store data on the disk if possible, use the database or BLOB storage.

• Setup and secure the backups as backups are most often left unsecured

• Define data retention policies• Logically deleted data must not be visible in the

application (except for the data recovery tools of the application) and must be explicitly excluded from all queries

Questions?