Secure Coding Training

8/3/2019 Secure Coding Training

1/26

INTRODUCTION TO SECURE CODING


2/26


3/26


4/26

AUTHENTICATION #2

3. Online Password GuessingApplications must defend against online password guessing

attempts by one of the following methods:

Account Lockout - Lock account after 5 failed passwordattempts

Temporary Account Lockout- Temporarily lock account after

5 failed password attempts

Anti-automation Captcha - Require a captcha to besuccessfully completed after 5 failed password attempts


5/26

AUTHENTICATION #3

4. Password Reset Functions

5. Email Verification Functions

If the application requires verification of ownership of anemail address then observe the following

Email verification links should only satisfy the requirement

of verify email address ownership and should not provide

the user with an authenticated session (e.g. the user must

still authenticate as normal to access the application).

Email verification codes must expire after the first use or

expire after 8 hours if not used.


6/26

AUTHENTICATION #4

6. Password Storage

Passwords should be stored in a format, such as

bcrypt, that is resistant to high speed offline brute

force attacks

Password storage using hashing algorithms plus a

per user salt are good, but not sufficient.


7/26


8/26

SESSION MANAGEMENT #2

4. Secure Flag The "Secure" flag should be set during every set-cookie. This will

instruct the browser to never send the cookie over HTTP. Thepurpose of this flag is to prevent the accidental exposure of a

cookie value if a user follows an HTTP link.

5. HTTP-Only Flag The "HTTP-Only" flag should be set to disable malicious script

access to the cookie values, such as the session ID

6. Logout Upon logout the session ID should be invalidated on the

server side and deleted on the client via expiring andoverwriting the value.


9/26

ACCESS CONTROL #1

1. Presentation Layer It is recommended to not display links or functionality that

is not accessible to a user. The purpose is to minimizeunnecessary access controls messages and minimizeprivileged information from being unnecessarily provided tousers.

2. Business Layer Ensure that an access control verification is performed

before an action is executed within the system. A usercould craft a custom GET or POST message to attempt toexecute unauthorized functionality.


10/26

ACCESS CONTROL #2

3. Data Layer Ensure that an access control verification is performed to

check that the user is authorized to act upon the target

data. Do not assume that a user authorized to performaction X is able to necessarily perform this action on all

data sets.


11/26

INPUT VALIDATION #1

1. Goal of Input ValidationInput validation is performed to minimize malformed datafrom entering the system. Input Validation is NOT theprimary method of preventing XSS, SQL Injection. Theseare covered in output encoding below. Input ValidationMust Be:

Applied to all user controlled data

Define the types of characters that can be accepted (oftenASCII 20h to 7Eh, though most special characters could beremoved and control characters are almost never needed)

Defines a minimum and maximum length for the data (e.g.{1,25} )


12/26

INPUT VALIDATION #2

2. Client Side vs Server Side Validation Be aware that any JavaScript input validation performed on the client

can be bypassed by an attacker that disables JavaScript or uses a Web

Proxy. Ensure that any input validation performed on the client is also

performed on the server.

3. Positive Approach The variations of attacks are enormous. Use regular

expressions to define what is good and then deny the input

if anything else is received. In other words, we want to use

the approach "Accept Known Good" instead of "Reject

Known Bad"


13/26

INPUT VALIDATION #3

4. Robust Use of Input ValidationAll data received from the user should be treated as malicious

and verified before using within the application. This includes

the following Form data

URL parameters

Hidden fields

Cookie data

HTTP Headers

Essentially anything in the HTTP request


14/26

INPUT VALIDATION #4

5. Validating Rich User Content

It is very difficult to validate rich content submitted

by a user. Consider more formal approaches such

as HTML Purifier (PHP), AntiSamy or bleach

(Python)

6. File Upload


15/26

OUTPUT ENCODING #1

1. Preventing XSS and Content SecurityPolicy

All user data controlled must be encoded when returned inthe html page to prevent the execution of malicious data(e.g. XSS). For example would be returned as

The type of encoding is specific to the context of the pagewhere the user controlled data is inserted. For example,HTML entity encoding is appropriate for data placed into the

HTML body. However, user data placed into a script wouldneed JavaScript specific output encoding

Detailed information on XSS prevention here: OWASP XSSPrevention Cheat Sheet


16/26

OUTPUT ENCODING #2

2. Preventing SQL Injection Parameterized queries should be used whenever a

method/function accepts data and uses this data as part of

the SQL statement. String concatenation to build any part of a SQL statement

with user controlled data creates a SQL injection

vulnerability.

Parameterized queries are a guaranteed approach toprevent SQL injection.

Further Reading: SQL Injection Prevention Cheat Sheet


17/26


18/26

OUTPUT ENCODING #4

4. Preventing XML Injection In addition to the existing input validation, define a positive

approach which escapes/encodes characters that can be

interpreted as xml. At a minimum this includes the following:< > " ' &

If accepting raw XML then more robust validation is

necessary. This can be complex. Please contact the

infrastructure security team for additional discussion


19/26


20/26

CROSS DOMAIN REQUEST FORGERY

#2

2. Preventing Malicious Site Framing

(ClickJacking) Set the x-frame-options header for all responses containing HTML

content. The possible values are "DENY" or "SAMEORIGIN". DENY will block any site (regardless of domain) from framing the

content.

SAMEORIGIN will block all sites from framing the content, except

sites within the same domain.

The "DENY" setting is recommended unless a specific need has

been identified for framing.


21/26

SECURE TRANSMISSION #1

1. When To Use SSL/TLS All points from the login page to the logout page must

be served over HTTPS.

Ensure that the page where a user completes the loginform is accessed over HTTPS. This is in addition toPOST'ing the form over HTTPS.

All authenticated pages must be served over HTTPS.This includes css, scripts, images. Failure to do socreates a vector for man in the middle attack and alsocauses the browser to display a mixed SSL warningmessage.


22/26

SECURE TRANSMISSION #2

2. Implement HTTP Strict Transport Security

(HSTS) Applications that are served exclusively over HTTPS should

utilize HSTS to instruct compatible browsers to not allowHTTP connections to the domain


23/26

FILE UPLOADS #1

1. Upload Verification Use input validation to ensure the uploaded filename uses an expected

extension type

Ensure the uploaded file is not larger than a defined maximum file size

2. Upload Storage

Use a new filename to store the file on the OS. Do not use

any user controlled text for this filename or for the

temporary filename.

Store all user uploaded files on a separate domain (e.g.

mozillafiles.net vs mozilla.org). Archives should be analyzed

for malicious content (anti-malware, static analysis, etc)


24/26

FILE UPLOADS #2

3. Public Serving of Uploaded Content Ensure the image is served with the correct content-type

(e.g. image/jpeg, application/x-xpinstall)

4. Upload Verification


25/26

FILE UPLOADS #3

5. Beware of "special" files The upload feature should be using a whitelist approach to only

allow specific file types and extensions. However, it is important tobe aware of the following file types that, if allowed, could result insecurity vulnerabilities.

"crossdomain.xml" allows cross-domain data loading in Flash,Java and Silverlight. If permitted on sites with authentication thiscan permit cross-domain data theft and CSRF attacks. Note thiscan get pretty complicated depending on the specific pluginversion in question, so its best to just prohibit files named"crossdomain.xml" or "clientaccesspolicy.xml".

".htaccess" and ".htpasswd" provides server configuration optionson a per-directory basis, and should not be permitted.Seehttp://en.wikipedia.org/wiki/Htaccess


26/26

REFERENCE

1. https://www.owasp.org/index.php/Secure_Co

ding_Cheat_Sheet

Secure Coding Training

Documents

Transcript of Secure Coding Training