An Eirtight internal presentation by our chief solution architect Leointin Birsan (Lusu the ghost). It is designed to help our team refocus on the importance of bearing in mind security when writing code.
2. 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.
3. 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.
4. 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.
5. 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.).
6. 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.
7. 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.
8. 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.
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
