web application security

53
Web Application Security by Example (for LAMP) Arpee Ong

Upload: arpee

Post on 08-May-2015

9.531 views

Category:

Technology


1 download

DESCRIPTION

Event: Tri{PHP}le Treat@USAutoparts Philippines hosted by PHPUGPH Topic: Web Application Security

TRANSCRIPT

Page 1: Web Application Security

Web Application Security by Example (for LAMP)Arpee Ong

Page 2: Web Application Security

Who Am I?

Name: Richard Peter Ong a.k.a. Arpee

Work: Lead Developer, Internal Projects at SysIQ Inc.

Open Source Affiliations: a.)core developer, MiaCMS

Page 3: Web Application Security

Who Are you?

✔ PHP Developers/Programmers✔ L/U/W AMP SysAdmins✔ IT Managers and Practitioners✔ Geeks and hackers..

Page 4: Web Application Security

Scope and Coverage:

●Securing a Basic U/L AMP Server

●Web Application Attacks Description, Samples and Prevention

Page 5: Web Application Security

WHAT IS A WEB APPLICATION?

✔ Any application that is served commonly via http or https protocol✔ Usually being served from a remote computer acting as a host/server

Page 6: Web Application Security

WHAT IS SECURITY?

✔ Is a State of being free from damage and being compromised✔ Is a condition of being protected against danger or loss

Page 7: Web Application Security

Levels of WebApp Security:

✔ Server Level✔ Application Level

Page 8: Web Application Security

Server Level Security:

✔ The Box(es) (physical or virtual server(s))✔ httpd (Apache)✔ mysqld (MySQL)✔ PHP

Page 9: Web Application Security

Secure the Box:

✔ Filesystem✔ Firewall

Page 10: Web Application Security

Filesystem:: File Ownership and Permission

✔ Folders should be 0755✔ Files should be 0644✔ Files and Folders under Document Root should be � owned� by the Apache User✔ 666 is evil, in the web world � well, so as 777.

Page 11: Web Application Security

Filesystem:: How to Set Permissions

✔ Folders

✔ Files

chmod 0755 {directory}

chmod 0644 {files}

Page 12: Web Application Security

Filesystem:: How to Set Ownership

✔ Files/Folders

chown -R {apache_user} {document_root}

Page 13: Web Application Security

Firewall::Opened Ports

✔ Port 80 � Web/Http ✔ Port 443 � Web/Https ✔ Port 21 � FTP✔ Port 22 � SSH✔ Port 25 � SMTP (outgoing)✔ Port 110 � POP (inbound)✔ Port 3306 � MySQL Daemon

Page 14: Web Application Security

Secure httpd (Apache):

✔ Set an apache user✔ Do not run apache as root✔ 3rd Party Tools:

✔ ModSecurity http://www.modsecurity.org/

Page 15: Web Application Security

Secure the mysqld (MySQL):

✔ Set root(admin) password✔ Rename the root(admin) account✔ Restrict Network Access✔ Use SSH Tunneling/Port Forwarding if necessary

Page 16: Web Application Security

MySQL::Set Admin Password

mysql -u rootmysql> SET PASSWORD FOR root@localhost=PASSWORD('password');mysql> FLUSH PRIVILEGES;

Page 17: Web Application Security

MySQL::Change Admin Username

mysql -u root -p{PASSWORD}mysql> update user set user="mydbadmin" where user="root";mysql> FLUSH PRIVILEGES;

Page 18: Web Application Security

MySQL::Why Restrict Network Access?

✔ Usually only your web application needs access to MySQL Server, NOTHING ELSE.

Page 19: Web Application Security

MySQL::How to Restrict Network Access?

✔ Open my.cnf✔ Add � skip-networking� parameter to mysqld or mysqld_safe (depending which you are using)

Page 20: Web Application Security

MySQL::How to tunnel mysql via ssh?

ssh -N -f -L 3306:localhost:3306 user@mysql_server.com

N � Do not execute command (useful for port forwarding only) f � Run in backgroundL � (port:host:hostport)

Page 21: Web Application Security

Secure php.ini (PHP):

✔ disable_functions✔ register_globals=off✔ allow_url_fopen=on/off✔ allow_url_include=off✔ 3rd Party Tools:

✔ Suhosinhttp://www.hardened-php.net/suhosin/

Page 22: Web Application Security

PHP::Functions to disable

✔ Exec() - executes a command✔ Passthru() - execute a command and display raw output

Page 23: Web Application Security

PHP::Register Globals

✔ DO NOT ENABLE register_globals✔ Write your apps to use SuperGlobals instead in initializing variables and its values whenever necessary. ($_GET, $_POST, $_REQUEST and $_SERVER)

Page 24: Web Application Security

PHP::allow_url_fopen, allow_url_include

✔ Allow_url_fopen � if set to on, allows treatment of URLs as files✔ Allow_url_include - if set to on, allows include/require to open URLs (like http:// or ftp://) as files.

Page 25: Web Application Security

PHP::misuse of register_globals, allow_url_fopen, allow_url_includealtogether >>

✔ SEE � remote file inclusion� attacks..

Page 26: Web Application Security

Application Level Security::Attack Samples and Prevention

✔ Remote File Inclusion✔ Form Spoofing✔ XSS � (Cross-Site Scripting)✔ CSRF � (Cross-Site Request Forgery)✔ SQL Injection✔ Session Fixation

Page 27: Web Application Security

Attack Description

Remote File Inclusion

Application Level Security::Remote File Inclusion

A Remote File Inclusion is a type of attack where an attacker executes a php script of his liking against the target web application

Page 28: Web Application Security

Attack Possible Damage

Remote File Inclusion

Application Level Security::Remote File Inclusion

● Expose/Modiy variable values of the script doing the include()

● Expose stored credentials eg. MySQL user/pass from a webapp configuration file

Page 29: Web Application Security

Attack Vectors

Remote File Inclusion

Application Level Security::Remote File Inclusion

● User-controllable value of variable called by include() or require()

Page 30: Web Application Security

Attack Prevention

Remote File Inclusion

● Disable register_globals● Disable allow_url_fopen● Disable allow_url_include● Do not include() from a dynamic variable with user controllable value

Application Level Security::Remote File Inclusion

Page 31: Web Application Security

Attack Description

Form Spoofing

Application Level Security::Form Spoofing

A type of an attack where an HTML Form is � mimicked� or copied and then submitted from a location different from the original

Page 32: Web Application Security

Attack Possible Damage

Form Spoofing

Application Level Security::Form Spoofing

● Bypass client-side validation

● Mass data insertion resulting to � flood� (eg. Flooded guestbooks, forum boards etc.)

Page 33: Web Application Security

Attack Vectors

Form Spoofing

Application Level Security::Form Spoofing

● No Form Tokens present, thus all requests thrown to the accepting script is considered valid

Page 34: Web Application Security

Attack Prevention

Form Spoofing● Tokenize the form● [optional]Check Referrer

Application Level Security::Form Spoofing

Page 35: Web Application Security

Attack Description

XSS

Application Level Security::XSS

Cross-Site scripting is a type of attack where an attacker inserts html code into the html output of the webapplication, usually a client-side code such as javascript. The � injected� html/js code script is then executed on the user browsers visiting the infiltrated web application

Page 36: Web Application Security

Attack Possible Damage

XSS

Application Level Security::XSS

● Steal/Fixate browser cookies and direct to another page

● Redirect user to another page

● Mess up a format of web application page

Page 37: Web Application Security

Attack Vectors

XSS

Application Level Security::XSS

● Unfiltered input forms

Page 38: Web Application Security

Attack Prevention

XSS

● � Do Not Trust User Input�Is not enough, I say, � Make User Input Trustable�● Filter incoming data

Application Level Security::XSS

Page 39: Web Application Security

Attack Description

CSRF

Application Level Security::CSRF

Cross-Site Request Forgery is a type of attack where an attacker forces an unknowing victim into making (malicious) http requests

Page 40: Web Application Security

Attack Possible Damage

CSRF

Application Level Security::CSRF

● Make victim execute an operation without his knowledge on a web application while being validy authenticated (eg. Change Account details, logout, spam etc.

Page 41: Web Application Security

Attack Vectors

CSRF

Application Level Security::CSRF

● XSS Vulnerabilities● Untokenized forms● Usage of $_GET for operations where $_POST may be best suited

Page 42: Web Application Security

Attack Prevention

CSRF

● Use $_POST instead of $_GET and/or $_REQUEST

● Filter incoming data● Tokenize

Application Level Security::CSRF

Page 43: Web Application Security

Attack Description

SQL Injection

Application Level Security::SQL Injection

An SQL Injection is an attack where an attacker is able to execute arbitrary sql code against the database

Page 44: Web Application Security

Application Level Security::SQL Injection: Basic Sample

//legit$sort = 'ASC';//malicious injection?$sort = '; TRUNCATE POSTS';

//actual query$query = "SELECT * FROM posts ORDER BY date_entered $sort";

// Output Query: uh-oh!SELECT * FROM posts ORDER BY date_entered; TRUNCATE POSTS

Page 45: Web Application Security

Attack Possible Damage

SQL Injection

Application Level Security::SQL Injection

● Corrupt data by executing truncate()

● Alter current DB data (eg. Change admin password)

Page 46: Web Application Security

Attack Vectors

SQL Injection

Application Level Security::SQL Injection

● Dynamic queries getting values from unsanitized user-submitted data

Page 47: Web Application Security

Attack Prevention

SQL Injection● Enclose user-submitted Values with mysql_real_escape_string()

Application Level Security::SQL Injection (MySQL)

Page 48: Web Application Security

Attack Description

Session Hijacking

Application Level Security::Session Hijacking

Session Hijacking is an attack where an attacker impersonates a legitimate user(commonly the administrator) that is currently logged in on the web application

Page 49: Web Application Security

Attack Possible Damage

Session Hijacking

Application Level Security::Session Hijacking

● Attacker gaining administrator privileges, damage/threat is highly serious.

Page 50: Web Application Security

Attack Vectors

Session Hijacking

Application Level Security::Session Hijacking

● Session ID Fixation via XSS● Web Application is not going thru HTTPS and therefore � sniffable�

● Session id is not regenerated when necessary

Page 51: Web Application Security

Attack Prevention

Session Hijacking

● Protect Site against XSS attacks (Fixation avoidance only)

● Regenerate SID whenever necessary and do not trust user-specified session id● Deliver the web app Over HTTPS to avoid getting � sniffed�

Application Level Security::Session Hijacking

Page 52: Web Application Security

In a nutshell:

● The Server Level is part of the Web Application. It is necessary to Secure the Server as well. 30% of Web Application Attacks are still suffered by the Server.

● � Do not Trust User Input� is not enough, � Make User Input TRUSTABLE� by filtering methods before they undergo processing.

● Tokenize your forms whenever necessary● Use SSL Layer (via https) in dealing with highly sensitive data to avoid being � sniffed� or � captured� .

Page 53: Web Application Security

I hope you enjoyed..

The End...