Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Threat modelling node.js applications

Threat modelling node.js applications

Threat modelling is the process of identifying potential threats in a prioritized way. When it comes to Node.js and JavaScript there are lots of specific security issues that can arise.

Presented at FullStack London, 2017

Gergely Nemeth

July 14, 2017
Tweet

More Decks by Gergely Nemeth

Other Decks in Programming

Transcript

  1. Threat modelling
    Node.js applications
    Gergely Nemeth | @nthgergo

    View Slide

  2. What’s civil engineering has
    to do with software security?

    View Slide

  3. 1977

    View Slide

  4. View Slide

  5. View Slide

  6. The most influential work
    for software design patterns

    View Slide

  7. 1994

    View Slide

  8. In 1988, Robert Barnard
    applied it for an IT attacker

    View Slide

  9. ● Threat modelling methodologies
    ○ Attack trees
    ○ STRIDE
    ○ DREAD
    ● Building more secure Node.js applications
    ○ HTTP Headers
    ○ Regex DDOS
    ○ XSS / CSRF attacks
    Agenda

    View Slide

  10. Attack trees

    View Slide

  11. Attack trees
    “A formal, methodical way of
    describing the security of systems,
    based on varying attacks.”
    Bruce Schneier

    View Slide

  12. Attack trees
    Get Access
    Modify
    Credentials
    Learn Password
    Bypass Access
    Control
    Get Access to
    Database
    Social
    Engineering
    Get Access to
    DMZ
    Listen on
    Transport Layer
    Guessing
    Insecure
    Dependencies

    View Slide

  13. Attack trees
    Get Access
    Modify
    Credentials
    Learn Password
    Bypass Access
    Control
    Get Access to
    Database
    Social
    Engineering
    Get Access to
    DMZ
    Listen on
    Transport Layer
    Guessing
    Insecure
    Dependencies
    Get Access
    Learn Password
    Guessing

    View Slide

  14. STRIDE

    View Slide

  15. Classification scheme for characterizing known threats:
    ● Spoofing of user identity
    ● Tampering
    ● Repudiation
    ● Information disclosure (privacy breach or data leak)
    ● Denial of service
    ● Elevation of privilege
    STRIDE

    View Slide

  16. Users impersonating other users
    STRIDE: Spoofing of user identity

    View Slide

  17. An attacker sending modified
    information, which the application
    may use and store without checking.
    STRIDE: Tampering

    View Slide

  18. Applications should have web
    access logs, audit trails at each tier.
    STRIDE: Repudiation

    View Slide

  19. Apps / browsers / content delivery
    networks leaking private data
    STRIDE: Information disclosure

    View Slide

  20. Make the service unavailable
    for other users.
    STRIDE: Denial of service

    View Slide

  21. Users getting rights that they should
    not have (like admin rights)
    STRIDE: Elevation of privilege

    View Slide

  22. DREAD

    View Slide

  23. Classification scheme for
    quantifying, comparing and
    prioritizing the amount of risk
    presented by each evaluated threat.
    DREAD

    View Slide

  24. ( DAMAGE
    + REPRODUCIBILITY
    + EXPLOITABILITY
    + AFFECTED USERS
    + DISCOVERABILITY ) / 5
    Calculating Risk:

    View Slide

  25. The DREAD calculation
    always produces a number
    between 0 and 10;
    the higher the number, the
    more serious the risk.

    View Slide

  26. DAMAGE: If a threat exploit occurs,
    how much damage will be caused?
    0 = None
    5 = Individual user data
    is compromised or affected.
    10 = Complete system or data destruction

    View Slide

  27. REPRODUCIBILITY: How easy is it
    to reproduce the exploit?
    0 = Very hard or impossible,
    even for administrators.
    5 = One or two steps required,
    may need to be an authorized user.
    10 = Even a web browser is sufficient,
    without authentication.

    View Slide

  28. EXPLOITABILITY: What is needed to
    exploit this threat?
    0 = Advanced programming and networking
    knowledge, with custom or advanced tool.
    5 = Malware exists on the Internet, or an exploit
    is easily performed, using available attack tools.
    10 = Just a web browser

    View Slide

  29. AFFECTED USERS:
    How many users will be affected?
    0 = None
    5 = Some users, but not all
    10 = All users

    View Slide

  30. DISCOVERABILITY:
    How easy is it to discover this threat?
    10 - Just assume it is always discoverable

    View Slide

  31. DREAD Example: SQL injection
    Damage: 10 (DROP TableName)
    Reproducibility: 5 (logged in state is needed)
    Exploitability: 10 (using forms)
    Affected users: 10 (everyone)
    Score: (10 + 5 + 10 + 10 + 10) / 5 = 9

    View Slide

  32. DREAD Example: XSS attack
    Damage: 5 (Individual user data is affected)
    Reproducibility: 5
    Exploitability: 10 (using forms)
    Affected users: 10 (everyone)
    Score: (5 + 5 + 10 + 10 + 10) / 5 = 8

    View Slide

  33. Securing Node.js
    Applications

    View Slide

  34. Securing HTTP

    View Slide

  35. Strict-Transport-Security enforces secure
    (HTTP over SSL/TLS) connections to the server
    X-Frame-Options provides clickjacking protection
    X-XSS-Protection enables the Cross-site scripting (XSS)
    filter built into most recent web browsers
    Content-Security-Policy prevents a wide range of attacks,
    including Cross-site scripting and other cross-site injections
    Security HTTP headers

    View Slide

  36. Use the helmet npm package -
    It automatically adds security headers.
    If you are building an express application,
    start the project with adding helmet.
    Security HTTP headers

    View Slide

  37. Security HTTP headers

    View Slide

  38. Side-channel attacks

    View Slide

  39. An attack based on information
    gained from the physical
    implementation of a cryptosystem
    Side-channel attacks

    View Slide

  40. - Power-monitoring attack
    - Data remanence
    - Acoustic cryptanalysis
    - Timing attack
    Side-channel attacks

    View Slide

  41. TIMING ATTACKS

    View Slide

  42. WRONG!
    TIMING ATTACKS

    View Slide

  43. T R A C E T R A C E
    1st iteration
    TIMING ATTACKS

    View Slide

  44. T R A C E T R A C E
    2nd iteration
    TIMING ATTACKS

    View Slide

  45. T R A C E T R A C E
    5th iteration
    TIMING ATTACKS

    View Slide

  46. T R A C E T R I C K
    1th iteration
    TIMING ATTACKS

    View Slide

  47. T R A C E T R I C K
    2nd iteration
    TIMING ATTACKS

    View Slide

  48. T R A C E T R I C K
    3rd iteration
    mismatch - no more iterations
    TIMING ATTACKS

    View Slide

  49. The more letters match from the
    password, the more time the
    comparison takes.

    View Slide

  50. Always use fixed-time
    comparison to avoid timing
    attacks.

    View Slide

  51. TIMING ATTACKS

    View Slide

  52. Denial of Service attacks

    View Slide

  53. DoS attackers seek to make a
    machine or network unavailable
    to its intended users.
    Denial of Service attacks

    View Slide

  54. Regex Denial of Service
    1
    ^(a+)+$
    2
    3
    4 5
    a a a
    a
    a
    a a a
    Nondeterministic finite automaton

    View Slide

  55. ^(a+)+$
    for the input “aaaaX”
    16 possible paths
    Regex Denial of Service

    View Slide

  56. ^(a+)+$
    for the input “aaaaaaaaaaaaaaaaX”
    65536 possible paths
    Regex Denial of Service

    View Slide

  57. Regular Expression
    implementations may reach
    extreme situations that cause
    them to work very slowly.
    Regex Denial of Service

    View Slide

  58. - Grouping with repetition (a+)+
    - Inside the repeated group:
    - Repetition (a+)+
    - Alternation with overlapping (a|aa)+
    Evil Regexes

    View Slide

  59. WE HAVE A
    SINGLE THREAD

    View Slide

  60. Regex Denial of Service

    View Slide

  61. Insecure dependencies

    View Slide

  62. YOU ARE WHAT
    YOU REQUIRE

    View Slide

  63. Insecure Dependencies

    View Slide

  64. Us

    View Slide

  65. 95% of all security incidents
    involve human error.

    View Slide

  66. We are the weakest link.

    View Slide

  67. Security is part of your job!

    View Slide

  68. - Node.js Security Checklist -
    https://blog.risingstack.com/node-js-security-checklist
    - Advisories of NSP - on nodesecurity.io
    - OWASP TOP 10 - on owasp.org
    WHAT’S NEXT?

    View Slide

  69. View Slide