Title Text

NODE.JS SECURITY - ADDICTION TO SELF DESTRUCT

BY ROMAN SACHENKO

NODE.JS SECURITY - ADDICTION TO SELF DESTRUCT

BY ROMAN SACHENKO

ABOUT ME

  • back-end developer
    and team lead at DA-14
  • ~ 3 years in
    software development area

I did everything wrong because I can do everything wrong

CONTENTS

Cyber Security - beginning for beginners

  • Web Apps Evolution
  • Secure App: myth or fact


NodeJS Vulnerabilities

  • Brute-Force Attacks
  • Database Injections
  • Regular Expression DOS
  • Memory Leaks
  • Hijacking the require chain
  • Rainbow Table attack

It's show time (c) Ben Richards

Painkiller

  • Best Practice
  • Helpful Modules

CYBER SECURITY - BEGINNING FOR BEGINNERS

Okay, now it's secure enough (c) noone ever

Application evolution

Before

 

 

 

 

 

Simple static websites with the same information for all user.

After

 

 

 

 

 

Huge complex applications with personal interface, stored data and high-level functionality.

CYBER SECURITY - BEGINNING FOR BEGINNERS

What's now:

  • Shopping (Amazon)
  • Social networking (Facebook, Instagram, Twitter etc.)
  • Banking (Citibank, Privat24)
  • Web search (Google)
  • Auctions (eBay)
  • Gambling (Betfair, Parimatch)
  • Blogs (Tech Crunch, LifeHacker, Blogger)
  • Web mail (Gmail)
  • Interactive information (Wikipedia)

etc.

CYBER SECURITY - BEGINNING FOR BEGINNERS

Is this application secure enough?

  • SSL is not the silver bullet

CYBER SECURITY - BEGINNING FOR BEGINNERS

Is this application secure enough?

  • Broken authentication
  • Broken access controls
  • Database injection
  • Cross-site scripting
  • Information leakage
  • Cross-site request forgery

CYBER SECURITY - BEGINNING FOR BEGINNERS

User can:

  • submit arbitrary input
  • interact with any pieces of transmitted data
  • send requests in any sequences 
  • submit parameters at different stages
  • use different tools to access application

User/Attacker can initiate a process of:

  • modifying a session token
  • modifying amount of provided parameters
  • altering input to process by back-end

CYBER SECURITY - BEGINNING FOR BEGINNERS

BEFORE WE START

Good developers code; Best developers copy (c) stack overflow

3rd party dependencies

your code

APP

MODERN APPLICATION

The most guaranteed but time-consuming method to crack a password

BRUTE-FORCE ATTACK

Guess:

  • 1.000.000.000 passwords/sec

Conditions:

  • 8 character password
  • 96 characters 

BRUTE-FORCE ATTACK

Guess:

  • 1.000.000.000 passwords/sec

Conditions:

  • 8 character password
  • 96 characters 

Result:

  • ~ 80 days

BRUTE-FORCE ATTACK

Guess:

  • 400.000.000.000 passwords/sec

Result:

  • < 6 hours

BRUTE-FORCE ATTACK

Best Practice:

  • Require strong passwords
  • Rate-limiting
  • Invalid login attempts locker 
  • Loggin
  • Secure password recover
    - Requires the old password
    - Secret question to prevent simple number, character
    - Ensure that the forgot password and other recovery paths do not reveal the current password

BRUTE-FORCE ATTACK

Painkiller

  • node-rate-limiter
  • proxy for limiting request (NginX)
  • queue service (Rabbit MQ, Apache Kafka etc.) for load balancing

BRUTE-FORCE ATTACK

DATABASE INJECTIONS

DB injection has been around for almost 20 years and is still a big issue 

Examples:

DELETE /users/?id=<userId>
UserModel.remove({ _id: req.query.id }); 

DATABASE INJECTIONS

Examples:

DELETE /users/?id=<userId>
UserModel.remove({ _id: req.query.id }); 
UserModel.remove({ _id: { '$exists': true } });
DELETE /users/?id={ '$exists': true }

DATABASE INJECTIONS

Examples:

db.<collection>.find( { $where: "this.<key> == 'a; sleep(1000000)'" } );
db.<collection>.find( { $where: "this.<key> == <value>" } );

DATABASE INJECTIONS

Best Practice:

  • validate incoming body and query parameters
  • be careful with the executable incoming data
  • create strict rules for incoming data
    - validate data type
    - check length
    - use value enumeration if it's possible
  • use ORM/ODM for database queries

 

DATABASE INJECTIONS

DATABASE INJECTIONS

REGULAR EXPRESSION DOS

RE implementations may reach extreme situations that cause them to work slowly

What the hell is the state machine and NFA?

REGULAR EXPRESSION DOS

Regular Expression: ^(a+)+$

Result:

aaaaX - 16 possible paths

aaaaaaaaaaaaaaaaX - 65536 possible paths

REGULAR EXPRESSION DOS

Evil Regular Expressions:

  • grouping with repetition
  • inside the repeated group
    - repetition
    - alternation with overlapping

     

REGULAR EXPRESSION DOS

REGULAR EXPRESSION DOS

MEMORY LEAKS

Tracking down memory leaks has always been a challenge

MEMORY LEAKS

heap

stack

resident set

retained size

shallow size

mark-sweep

scavenge

old space

new space

Common Reasons:

  • forgotten timers or callbacks
  • weak closures
  • insecure dependencies 
  • buggy technology
    - new Buffer(size) (deprecated, but still)

MEMORY LEAKS

MEMORY LEAKS

HIJACKING THE REQUIRE CHAIN

Hooking all asynchronous core methods is definitely possible

HIJACKING THE REQUIRE CHAIN

A

B

C

HIJACKING THE REQUIRE CHAIN

A

B

C

D

C

E

HIJACKING THE REQUIRE CHAIN

A

B

C

D

C

E

PATCH

HIJACKING THE REQUIRE CHAIN

  • wait for D module to be included first
  • require() is synchronous

HIJACKING THE REQUIRE CHAIN

B

A

D

C

E

C

APPLICATION

CACHED

HIJACKING THE REQUIRE CHAIN

Painkiller:

HIJACKING THE REQUIRE CHAIN

Rain Bow Table attack must be weird enough...

RAINBOW TABLE

Theory:

  • a precomputed table of <password> - <hash> pairs (ex. for most common passwords.) for reversing cryptographic hash functions​
  • can be generated according to encryption type/way and existing hash

RAINBOW TABLE

Best Practice:

  • don't use Math.random() to generate a random password
  • use personal salt 
  • use well known cryptographic modules (crypto)

RAINBOW TABLE

BEST PRACTICE

May the 4th be with you

  • Limit requests frequency
  • Use database ORM (mongoose, sequelize)
  • Don't accept or use carefully query params as database query items
  • Validate incoming body, query params
  • Validate incoming body schema
  • Hide 'X-Powered-By' header
  • Set strong access control system
  • Use SSL
  • Care about regular expressions
  • Use Security check tools (nodesecurity)
  • OWASP top 10 (http://nodegoat.herokuapp.com/tutorial)

 

BEST PRACTICE

HELPFUL MODULES

Let off some steam

Protection

Validation

Package Security Check

Rate Limiting

 

Memory Check

 

Other

HELPFUL MODULES

ARTICLES

Do they speak English in What?

ARTICLES

QUESTIONS?

*and again I couldn't find a funny meme for this page

roman.sachenko@gmail.com

roman.sachenko

CONTACTS

NodeJS Security - Addiction To Self Sestruct

By Roman Sachenko

NodeJS Security - Addiction To Self Sestruct

There are dozens of mistakes that can be easily made and lead to huge security problems. On the other hand, there are even more ways to break an application, such as DB injections, brute-force attacks, regular expression DOS, memory leaks, and hijacking require chain, just to name a few. During the presentation, I’ll list the most common security problems, talk about the current situation in WEB and will explain how to deal with safety concerns. What can we do to decrease the level of 'insecurity'? I'll teach the audience to deal with security holes and will explain the must-steps which should be performed before launching a new application.

  • 852
Loading comments...

More from Roman Sachenko