L3 - Secure Coding Techniques

Question 1

CWE

Answer 1

They help developers and security practitioners to:
*Describe and discuss software and hardware weaknesses in a common language.
* Check for weaknesses in existing software and hardware products.
* Evaluate coverage of tools targeting these weaknesses.
* Leverage a common baseline standard for weakness identification, mitigation, and prevention efforts.
* Prevent software and hardware vulnerabilities prior to deployment.

Question 2

CWE 3 metric groups

Answer 2

Base Finding
- captures the inherent risk of the weakness, confidence in the accuracy of the finding, and strength of controls.
Attack Surface
- the barriers that an attacker must overcome in order to exploit the weakness
Environmental
- characteristics of the weakness that are specific to a particular environment or operational context

Question 3

Common Weakness Scoring System (CWSS)

Answer 3

Three subscores are multiplied together, which produces a CWSS score between 0 and 100. The higher the score, the higher the vulnerability.

Question 4

Improper input validation

Answer 4

When software does not validate the input properly, an attacker is able to craft the input in a format that is not expected by the rest of the application.
This will lead to
- unintended input resulting in alterted control flow or code execution
- SQL injection attack
- Buffer overflow attack
Examples:
- no .pdf or .zip extension
- file large than 100kB
- special charcters

Question 5

Input validation function

Answer 5

Prevents improperly formed data from entering an information system

Question 6

What is input validation

Answer 6

• Only allow specific file content extensions
• All input from all sources must be carefully validated
• Limit maximum input character length (eg: 20 characters)
• Number bounds (min & max)
• Watch out for special characters

Question 7

Input validation strategies

Answer 7

• Classification strategy (Input Filtering)
  – User input can be classified using either blacklisting or whitelisting.
• Validation outcome
  – User input identified as malicious can either be rejected or sanitised.

Question 8

Input Filtering

Answer 8

Whitelisting - Allowing only the known good characters
Blacklisting - Allowing anything except the known bad characters

Question 9

Whitelisting vs Blacklisting

Answer 9

• When building secure software, whitelisting is the
  recommended minimal approach.
• Blacklisting is prone to error and can be bypassed with
  various evasion techniques. However, it can be useful
  to help detect obvious attacks. (e.g keywords like
  

   in the input textbox)

• Usage
  – whitelisting helps limit the attack surface by ensuring data
  is of the right semantic validity.
  – blacklisting helps detect and potentially stop obvious
  attacks.

Question 10

Regular expression

Answer 10

Regular expressions offer a way to check
whether data matches a specific pattern
(Whitelist)

Question 11

Flexible Matching

Answer 11

• star () matches any number of instances
  /abc/ => ‘a’ followed by zero or more ‘b’ followed by ‘c’
• plus (+) matches at least one instance
  /ab+c/ => ‘a’ followed by 1 or more ‘b’ followed by ‘c’
• question mark (?) matches zero or one instance
  /ab?c/ => ‘a’ followed by 0 or 1 ‘b’ followed by ‘c’

Question 12

More flexibility

Answer 12

• {x} will match x number of instances.
  /ab{3}c/ => abbbc
• {x,y} will match between x and y instances.
  /a{2,4}bc/ => aabc or aaabc or aaaabc
• {x,} will match x+ instances.
  /abc{3,}/ => abccc or abccccccc or abcccccccc

Question 13

More flexibility

Answer 13

• {x} will match x number of instances.
  /ab{3}c/ => abbbc
• {x,y} will match between x and y instances.
  /a{2,4}bc/ => aabc or aaabc or aaaabc
• {x,} will match x+ instances.
  /abc{3,}/ => abccc or abccccccc or abcccccccc
• dot (.) is a wildcard character – matches
  any character except new line (\n)
• /a.c/ => ‘a’ followed by any character followed by ‘c’
• Combine metacharacters
  /a.{4}c/ => ‘a’ followed 4 instances of any character followed by ‘c’ so will match
• addddc
• Afgthc
• ab569c

Question 14

Security Strategies (SD3 +C)

Answer 14

Secure by Design, Secure by Default, Secure by Deployment, Secure in Communications

Question 15

Secure by Design

Answer 15

– This means that developers follow secure coding best
practices and implement security features in their
applications to overcome vulnerabilities.
– Ensure that the software design is secured right from
the start.
– Bad software design can make software difficult to
secure later.
– E.g: your application handles sensitive data, so you
will encrypt the data and protect it from theft and
tampering. This consideration to use cryptography in
your application is done at the design stage.

Question 16

Secure by Default

Answer 16

– Least privilege. Allow each user/process minimum privileges to do his/its work.
– Defense in depth. Design software that will not easily break down just because one security mechanism has been broken. If possible, employ multiple security mechanisms such that an attacker would need to breach
several layers before being successful.
– Conservative default settings. The development team is aware of the attack surface for the product and minimizes it in the default configuration
– Avoidance of risky default changes to operating system or security settings
– Less commonly used services deactivated by default.

Question 17

Secure by Deployment

Answer 17

– This means that applications can be maintained securely after deployment by updating with security patches, monitoring for attacks, and by auditing for malicious users and content.
– Security functions must be easily administered by users.
– Software must be easily patched to allow for security patches, if required.
– In the event of application failure or errors, these events should be logged so that administrators can help resolve the issues.

Question 18

Secure in Communications

Answer 18

– Security response: Development teams responding promptly to reports of security vulnerabilities and communicate information
about security updates.
– Community engagement: Development teams proactively engage with users to answer questions about security vulnerabilities, security updates, or changes in the security landscape.

Question 19

Security Principles

Answer 19

• Minimize attack surface area
• Employ secure defaults
• Assume external systems are insecure
• Never depend on security through obscurity alone
• Fail safely
• Remember that security features != security

Question 20

Minimize attack surface area

Answer 20

– Reduce potential points of entry from which attackers can take advantage of.
– In particular, take note of the following:
* Services running in elevated privilege
* Services that are running by default
* Applications that are running
* Open ports
* Open named pipes
* Accounts with administrative rights
* Files, directories and registry keys with weak access control
lists (ACLs)

Question 21

Employ secure defaults

Answer 21

– Most users would choose the defaults when installing your software.
– Ensure default settings/services are necessary and not exploitable by hackers.
– E.g. Windows 2000 installs IIS by default. This allows hackers to attack systems through the IIS.

Question 22

Assume external systems are insecure

Answer 22

– For all data that is received from external sources, consider them to be possibly from attackers.
– Filter these data for validity before allowing them into the system.

Question 23

Never depend on security through obscurity alone

Answer 23

– Always assume that the attacker knows everything you know.
– Obscurity is a useful defense only when it is not the only defense.
– Attackers can easily find information that you try to hide.

Question 24

Fail safely

Answer 24

– Design your program to recover or terminate ‘gracefully’ upon any form of failure.
– When the application fails, ensure that data is not lost or disclosed to unauthorized parties.