How Your Laravel Application Can Get Hacked, And How to Prevent That From Happening?

How Your Laravel Application Can Get Hacked, And How to Prevent That From Happening?

In this talk I go through 4 common development flaws and mistakes that can lead your Laravel application being compromised in production.

The actual hands-on demonstrations aren't _really_ visible from the slides, they can be seen from the recording of this talk published in Youtube later.

73b9c5161bb047391fd949f8089b9396?s=128

Antti Rössi

May 23, 2019
Tweet

Transcript

  1. How your Laravel application can get hacked, and how to

    prevent that from happening? Antti Rössi, Laracon EU - Madrid 2019
  2. # whoami Helsinki, Finland CTO @ Jobilla Oy During daytime

    I build a digital software product. During night-time I hack software in order to make it more secure. (CTFs, pentesting, bug bounties) #pystyyvetää
  3. !! Disclaimer !! All material and examples in this talk

    are for educational use only. The term ‘hacking’ in this presentation refers to ‘ethical hacking’ and should not be confused with ‘black hat hacking’, meaning attacking or attempting to attack any application, systems or network unauthorized. Hacking or attempting to hack anything you don’t own is by default illegal. Doing so will eventually get you in jail. Please act responsibly. I as the author is this presentation, nor any author of the tools used in this presentation shall not be responsible for any individual performing illegal actions with the tools or methods used in this presentation. The intent of this presentation and of all the demonstrations involved, is to help professional software developers to write more secure software.
  4. None
  5. What’s coming?

  6. 4 common exploits and/or attacks that you will face in

    the wild as a Laravel developer
  7. Is Laravel secure?

  8. No framework or technology can ever guarantee that your application

    is impenetrable.
  9. Laravel gives you an excellent modern base to build secure

    applications with.
  10. Your application is as secure as its weakest link. Take

    in account all dependencies and the whole supply chain of every single component.
  11. All of the following attacks exploit vulnerabilities caused by an

    engineering flaw by either the developers, or the admins of the example application. NOT BY LARAVEL FRAMEWORK
  12. XSS Attack (Cross Site Scripting)

  13. XSS Attack Attacker executes a malicious script in the victims

    browser. Usually targets sensitive information like authentication tokens.
  14. {{-- Echoing unescaped content into a blade template exposes a

    XSS vulnerability --}} <span>Title: {!! $msg!"title !!}</span> <span>Message: {!! $msg!"body !!}</span>
  15. Round 1 fight!

  16. SQL Injection (there’s also a NoSQL injection…)

  17. SQL Injection Attacker injects malicious SQL queries into eg. an

    HTTP request. Can lead to a full disclosure of the DB content when successful.
  18. DB#$raw("select * from users order by $order desc");

  19. SQL Injection Certain edge cases can be very hard to

    spot in code reviews.
  20. SQL Injection Easy to test & exploit with proper tooling.

  21. Round 2 fight!

  22. Malicous File Uploads (& Remote Code Execution, RCE)

  23. Malicious File Uploads Improperly validated file uploads can allow an

    attacker to upload & run malicious scripts on the target machine.
  24. Malicious File Uploads Around half of the tutorials I found

    for ‘How to Upload Files with Laravel’ online don’t mention filetype validation at all…
  25. Malicious File Uploads Malicious uploads easily lead to remote code

    execution on the target machine.
  26. Round 3 fight!

  27. Final Boss Privilege Escalation Attack

  28. Privilege Escalation Exploiting a bug, design flaw, or configuration flaw

    to access resources that would otherwise require higher privileges than what’s currently available.
  29. Privilege Escalation Eg. find a process that’s running as root,

    and exploit that.
  30. Privilege Escalation Very few things should ever run as root

    on the host machine.
  31. Privilege Escalation Artisan scheduler is certainly not one of these

    things.
  32. Round 4 fight!

  33. How to not get hacked?

  34. Tip #1 Do not trust user input of any format.

    Validate everything, sanitise everything.
  35. 'file' %& 'mimes:jpeg,gif,png'

  36. htmlspecialchars($string, ENT_QUOTES, 'UTF-8');

  37. <span>Title: {{ $msg!"title }}</span>

  38. Tip #2 Do not run outdated software in production.

  39. None
  40. Tip #3 Do not run code that you don’t understand

    in production. Eg. copy-pasting code from online tutorials.
  41. Tip #4 Follow the principle of least privilege. Both in

    your application, and on your production host.
  42. Tip #5 Automate everything that’s reasonably possible. This reduces the

    chance of human error, and makes your environments & configs easier to audit.
  43. Tip #6 Don’t leave utilities that you don’t need on

    a production machine. (nc, gcc, etc…) Why was netcat enabled?
  44. Closing Words

  45. Security is not a one-time effort that you can tick

    off your to-do list.
  46. It’s an infinite ongoing process, and requires you to pay

    attention to it every single day you write or run code.
  47. –Uncle Ben, Spiderman “With great power comes great responsibility.”

  48. Thanks! Twitter: anamus_ Blog: coming soon! Shoutout to Joona Hoikkala

    (@joohoi) for fact checking the talk in beforehand. #pystyyvetää