Slide 1

Slide 1 text

How your Laravel application can get hacked, and how to prevent that from happening? Antti Rössi, Laracon EU - Madrid 2019

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

What’s coming?

Slide 6

Slide 6 text

4 common exploits and/or attacks that you will face in the wild as a Laravel developer

Slide 7

Slide 7 text

Is Laravel secure?

Slide 8

Slide 8 text

No framework or technology can ever guarantee that your application is impenetrable.

Slide 9

Slide 9 text

Laravel gives you an excellent modern base to build secure applications with.

Slide 10

Slide 10 text

Your application is as secure as its weakest link. Take in account all dependencies and the whole supply chain of every single component.

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

XSS Attack (Cross Site Scripting)

Slide 13

Slide 13 text

XSS Attack Attacker executes a malicious script in the victims browser. Usually targets sensitive information like authentication tokens.

Slide 14

Slide 14 text

{{-- Echoing unescaped content into a blade template exposes a XSS vulnerability --}} Title: {!! $msg!"title !!} Message: {!! $msg!"body !!}

Slide 15

Slide 15 text

Round 1 fight!

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

SQL Injection Attacker injects malicious SQL queries into eg. an HTTP request. Can lead to a full disclosure of the DB content when successful.

Slide 18

Slide 18 text

DB#$raw("select * from users order by $order desc");

Slide 19

Slide 19 text

SQL Injection Certain edge cases can be very hard to spot in code reviews.

Slide 20

Slide 20 text

SQL Injection Easy to test & exploit with proper tooling.

Slide 21

Slide 21 text

Round 2 fight!

Slide 22

Slide 22 text

Malicous File Uploads (& Remote Code Execution, RCE)

Slide 23

Slide 23 text

Malicious File Uploads Improperly validated file uploads can allow an attacker to upload & run malicious scripts on the target machine.

Slide 24

Slide 24 text

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…

Slide 25

Slide 25 text

Malicious File Uploads Malicious uploads easily lead to remote code execution on the target machine.

Slide 26

Slide 26 text

Round 3 fight!

Slide 27

Slide 27 text

Final Boss Privilege Escalation Attack

Slide 28

Slide 28 text

Privilege Escalation Exploiting a bug, design flaw, or configuration flaw to access resources that would otherwise require higher privileges than what’s currently available.

Slide 29

Slide 29 text

Privilege Escalation Eg. find a process that’s running as root, and exploit that.

Slide 30

Slide 30 text

Privilege Escalation Very few things should ever run as root on the host machine.

Slide 31

Slide 31 text

Privilege Escalation Artisan scheduler is certainly not one of these things.

Slide 32

Slide 32 text

Round 4 fight!

Slide 33

Slide 33 text

How to not get hacked?

Slide 34

Slide 34 text

Tip #1 Do not trust user input of any format. Validate everything, sanitise everything.

Slide 35

Slide 35 text

'file' %& 'mimes:jpeg,gif,png'

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Title: {{ $msg!"title }}

Slide 38

Slide 38 text

Tip #2 Do not run outdated software in production.

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

Tip #3 Do not run code that you don’t understand in production. Eg. copy-pasting code from online tutorials.

Slide 41

Slide 41 text

Tip #4 Follow the principle of least privilege. Both in your application, and on your production host.

Slide 42

Slide 42 text

Tip #5 Automate everything that’s reasonably possible. This reduces the chance of human error, and makes your environments & configs easier to audit.

Slide 43

Slide 43 text

Tip #6 Don’t leave utilities that you don’t need on a production machine. (nc, gcc, etc…) Why was netcat enabled?

Slide 44

Slide 44 text

Closing Words

Slide 45

Slide 45 text

Security is not a one-time effort that you can tick off your to-do list.

Slide 46

Slide 46 text

It’s an infinite ongoing process, and requires you to pay attention to it every single day you write or run code.

Slide 47

Slide 47 text

–Uncle Ben, Spiderman “With great power comes great responsibility.”

Slide 48

Slide 48 text

Thanks! Twitter: anamus_ Blog: coming soon! Shoutout to Joona Hoikkala (@joohoi) for fact checking the talk in beforehand. #pystyyvetää