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.

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.
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.
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ää