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

How Your Laravel Application Can Get Hacked?

How Your Laravel Application Can Get Hacked?

You’ve probably heard about XSS, SQL Injection, and RCE. Very few developers out there have actually witnessed first-hand what exploiting any of the mentioned vulnerabilities looks like, and therefor don’t necessarily understand the consequences that having such vulnerabilities in your application can have. In this talk we’ll exploit some commonly known vulnerabilities and misconfigurations that can occur to a Laravel application running on a Linux based host. By learning to think like a hacker you’ll be able to develop more secure applications with Laravel, and to keep yourself, your clients, and your users data safe.

Antti Rössi

August 29, 2019
Tweet

More Decks by Antti Rössi

Other Decks in Programming

Transcript

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

    prevent that from happening? Antti Rössi Laracon EU - Amsterdam 2019
  2. whoami Antti Rössi Helsinki, Finland CTO, Partner @ Jobilla Oy

    During daytime I’m building a digital software product. During night-time I hack software in order to make it more secure. (CTFs, pentesting, bug bounties, reversing…) @anamus_
  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. @anamus_
  4. SQL Injection Can lead to a full disclosure of the

    DB content when successful. @anamus_
  5. Stream Wrappers in PHP file:// — Accessing local filesystem http://

    — Accessing HTTP(s) URLs ftp:// — Accessing FTP(s) URLs php:// — Accessing various I/O streams zlib:// — Compression Streams data:// — Data (RFC 2397) glob:// — Find pathnames matching pattern phar:// — PHP Archive ssh2:// — Secure Shell 2 rar:// — RAR ogg:// — Audio streams expect:// — Process Interaction Streams @anamus_
  6. Stream Wrappers in PHP file:// — Accessing local filesystem http://

    — Accessing HTTP(s) URLs ftp:// — Accessing FTP(s) URLs php:// — Accessing various I/O streams zlib:// — Compression Streams data:// — Data (RFC 2397) glob:// — Find pathnames matching pattern phar:// — PHP Archive ssh2:// — Secure Shell 2 rar:// — RAR ogg:// — Audio streams expect:// — Process Interaction Streams @anamus_
  7. class Logger { public $file = 'log.txt'; public $data =

    'testing'; public function __construct() { // ... } public function switchContext() { // ... } } @anamus_
  8. public function __wakeup() { // called upon deserialisation } public

    function __destruct() { // called before garbage collection } @anamus_
  9. copy file_exists file_get_contents file_put_contents file fileatime filectime filegroup fileinode filemtime

    fileowner fileperms filesize filetype fopen is_dir is_executable is_file is_link is_readable is_writable lstat mkdir parse_ini_file readfile rename rmdir stat touch unlink @anamus_
  10. copy file_exists file_get_contents file_put_contents file fileatime filectime filegroup fileinode filemtime

    fileowner fileperms filesize filetype fopen is_dir is_executable is_file is_link is_readable is_writable lstat mkdir parse_ini_file readfile rename rmdir stat touch unlink @anamus_
  11. 1. Take an image file 2. Hide malicious PHAR file

    in it 3. Call filesize() on it with phar:// 4. Object from PHAR metadata gets injected in application runtime 5. Gadget kicks in on __destruct() @anamus_
  12. Tip #1 Do not trust user input of any format.

    Validate everything. Sanitise everything. @anamus_
  13. Tip #3 Do not run code that you don’t understand

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

    your application, and on your production host. @anamus_
  15. Tip #5 Learn to think like a hacker. And preferably

    the basics of hacking. @anamus_
  16. Security is not a one- time effort that you can

    tick off your to-do list. @anamus_
  17. It’s an infinite ongoing process, and requires you to pay

    attention to it every single day you write or run code. @anamus_