InSite responses – CWE/SANS Top 25 Most Dangerous Software Errors

CWE/SANS Top 25 Most Dangerous Software Errors

CWE/SANS Top 25 Most Dangerous Software Errors ID + full details Vendors description on how each error has been mitigated in their product
Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) CWE-89 InSite is not using any SQL or relational databases, so this item is not applicable: http://docs.mongodb.org/manual/faq/developers/#how-does-mongodb-address-sql-or-query-injection. We do allow JavaScript execution in the Mongo DB server, specifically in $where and group, but we never allow unfiltered user input in these queries (they are only used for statistics calculations based on fixed queries specified as a JSON, not a string).
Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’) CWE-78 InSite doesn’t execute shell commands. It doesn’t need to and won’t do it for security reasons. We do run shell commands via cron and Grunt (http://gruntjs.com/), but neither use any user input.
Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’) CWE-120 Buffer overflow is not applicable to JavaScript (InSite is written in JavaScript): http://cwe.mitre.org/data/definitions/120.html. The underlying platform and some libraries are still vulnerable and we are watching security alerts closely and updating the server software daily in order to promptly solve potential security problems in the system software as they are discovered in the future.
Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) CWE-79 We do not output unfiltered user-controllable input to the site. More specifically we are using the EJS template engine, which by default escapes everything and we do not use un-escaped constructs. We also use Angular.js that provides an additional level of protection: https://docs.angularjs.org/misc/faq. Finally we also set X-XSS-Protection header (via helmet).
Missing Authentication for Critical Function CWE-306 All possible URLs (routes) in InSite are centralized and all of them require authentication except for the limited functionality required to recover user password. Node.js+passport.js+express routing system is extremely helpful in protecting against this kind of attack: http://passportjs.org/guide/ (we have only enabled local authentication and disabled all other strategies: https://github.com/jaredhanson/passport-local)
Missing Authorization CWE-862 The current version of InSite only has one user role, so this is not applicable. If we need to implement multiples roles/groups/permissions in the future we plan to use this library: https://github.com/ForbesLindesay/connect-roles. This is another place where Express centralized routing allows us to quickly and reliably define the authorization levels.
Use of Hard-coded Credentials CWE-798 InSite doesn’t use any hardcoded credentials. All user credentials are stored in the database, The passwords are salted and hashed.
Missing Encryption of Sensitive Data CWE-311 All authentication is done via HTTPS (using jsonp), but other communications with the server are currently possible via both HTTP and HTTPS. Please let us know if you prefer HTTP to be disabled completely. We only store salted hashes of the InSite user passwords. We do not store Jive passwords in the system in any form. We also offer option of complete database encryption via Vormetric for an additional fee: http://www.vormetric.com/company/newsroom/press-releases/vormetric-and-mongodb-deliver-breakthrough-encryption-performance.
Unrestricted Upload of File with Dangerous Type CWE-434 In the current implementation of InSite, the only type of file we allow on the server is .csv list of users to send emails to. This file is parsed immediately and not stored in the system. We plan to allow users to change avatars in the future versions and will verify the content type and the contents itself.
Reliance on Untrusted Inputs in a Security Decision CWE-807 InSite uses sessions to keep track of the users, never a user input or a generic cookie.
Execution with Unnecessary Privileges CWE-250 The application server and the database server are being executed under appropriate user accounts
Execution with Unnecessary Privileges CWE-250 The application server and the database server are being executed under appropriate user accounts
Cross-Site Request Forgery (CSRF) CWE-352 We use both Express CSRF middleware and Angular $http CSRF protection similar to this: http://www.mircozeiss.com/using-csrf-with-express-and-angular/
Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) CWE-22 InSite doesn’t manipulate files on the local file system. We might need to do this in the future and we will follow the guidelines for filtering the paths. Also some libraries we use might be vulnerable, so we’re monitoring security alerts and we update the system daily. https://nodesecurity.io/advisories, http://www.linuxsecurity.com/content/blogcategory/98/110/, provider news, etc.
Download of Code Without Integrity Check CWE-494 InSite doesn’t download code at all.
Incorrect Authorization CWE-863 Using Express and Passport.js leaves virtually no space for this vulnerability.
Inclusion of Functionality from Untrusted Control Sphere CWE-829 We use package managers that do code signature verification: yum, npm. All libraries on the webpage originate from our server. We do not use 3rd party widgets. We only use stable, common and trusted libraries.
Incorrect Permission Assignment for Critical Resource CWE-732 Currently InSite has only one role. In the future we plan to use the solution described in CWE-862 response above.
Use of Potentially Dangerous Function CWE-676 In general this is not applicable to JavaScript.
Use of a Broken or Risky Cryptographic Algorithm CWE-327 We only use modern industry-standard cryptographic algorithms and libraries. SSL is terminated with nginx: https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx, ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;
Passport.js uses pbkdf2 hash algorithm.
Incorrect Calculation of Buffer Size CWE-131 Not applicable to JavaScript applications.
Improper Restriction of Excessive Authentication Attempts CWE-307 We do not implement this at the moment, but we can easily add protection upon your request with passport-local-mongoose strategy for Passport.js: https://github.com/saintedlama/passport-local-mongoose
URL Redirection to Untrusted Site (‘Open Redirect’) CWE-601 InSite doesn’t use this technique for redirects (we only use sessions or app logic for redirects).
Uncontrolled Format String CWE-134 We only allow this type of record delimiter in .csv files uploaded by user, and we use a library (node-csv) that verifies the file format.
Integer Overflow or Wraparound CWE-190 Not applicable to JavaScript (JavaScript doesn’t allow either overflow or underflow of an integer: http://stackoverflow.com/questions/19054891/does-javascript-handle-integer-overflow-and-underflow-if-yes-how).
Use of a One-Way Hash without a Salt CWE-759 InSite uses salt for hashing InSite user passwords. We don’t store any other passwords.