Information Security Training. Assignment 3 Web Application Security
|
|
- Marlene Hunt
- 6 years ago
- Views:
Transcription
1 Information Security Training Assignment 3 Web Application Security By Justin C. Klein Keane <jukeane@sas.upenn.edu>
2 Setting Up In order to complete this portion of the training you will need to use a CentOS 6 virtual machine with Apache, PHP, and MySQL installed. Issuing the following command should install all of the necessary packages: $ sudo yum install httpd mysql php mysql mysql server php php mbstring php common php xml php gd php cli Next make sure each of these is set to start at runlevels 3, 4, and 5 using the commands: $ sudo /sbin/chkconfig level 345 httpd on $ sudo /sbin/chkconfig level 345 mysqld on Modify your firewall by adding the following line to /etc/sysconfig/iptables: A INPUT m state state NEW m tcp p tcp dport 80 j ACCEPT Immediately after the line that lists '--dport 22' and restart the firewall using: $ sudo /sbin/service iptables restart Then make sure to start Apache and MySQL using: $ sudo /sbin/service httpd start ; sudo /sbin/service mysqld start Finally ensure that SELinux is disabled on your virtual machine. Next find the ipaddress of the virtual machine using the 'ifconfig' command and point a web browser on your host machine to that ip address. You should see the Apache welcome screen. If not check your logs (/var/log/messages and /var/log/httpd/error_log) for indications of any issue. Once your web server is set up and running you should download the training exercise onto the machine. Use the following commands, as root: # cd /var/www/html # wget # unzip madirish_training.zip # cd madirish # mysql u root < sql/db.sql This will create the database for the application. Once this is done you can point a web browser at the IP address of the virtual machine's IP address plus '/madirish' (for instance: and ensure that the application is running properly:
3 Once you've completed the exercises you may want to see if you can 'fix' the test site so that it's no longer vulnerable to the exploits described below. Be sure to delete the test site when you're done or keep it behind a firewall, since it's deliberately designed to be insecure and could be used to compromise your computer!
4 Cross Site Scripting Cross site scripting (CSS or XSS) is a common web application vulnerability that can allow a malicious user to abuse an application in many ways. The test site has several XSS vulnerabilities. The first of these is presented by the way the application handles failed logins. Pull up the application page and attempt to log in using any made up username and password. You'll note that the application correctly handles the error message by not revealing whether or not the user exists. For instance, some applications may respond to a failed login with a message such as 'password incorrect' or 'user account does not exist'. These types of messages leak information about the failed login that can be useful for an attacker. For instance, if an attacker is trying to brute force an account they must correctly guess the account name and password. Brute forcing is an attack based on guessing. For instance, the attacker could simply try one username with every password they could think of, then move on. Computers are quite good at brute forcing, with automated attack programs that can tirelessly guess usernames and passwords. Given enough time any username and password combination can be guessed by a computer. Giving the attacker clues as to whether an account exists reduces the time it takes to brute force that account because the attacker does not have to guess at account names, merely passwords. The sample application correctly alerts the users that their login attempt failed, but does not hint as to whether or not it was the username or password that did not match. However, there is a critical flaw in how the application alerts the user to this fact. Can you spot the flaw? Can you exploit this flaw to cause the page to redirect to " Try logging in with an incorrect username and password. You'll notice that a Javascript prompt shows up telling you that you failed to log in. Now, examine the URL for the page. Next examine the source code for the page (Ctrl+u in your browser). You'll see there is a URL "GET" variable that is included as part of the page. The URL "index.php?msg=sorry,%20could%20not%20log%20in%20with%20those %20credentials." includes the message that is included as part of the alert. Looking at the source we can see: <script>alert('sorry, could not log in with those credentials.');</script> Try changing the URL so that it reads something else, for instance, try going to the URL "index.php? msg=foo" and observe what happens, view the resulting page source code. Can you spot the flaw yet? Try exploiting this get variable's inclusion into the javascript. Type the URL "index.php? msg=foo');alert('bar" into your web browser and observe what happens. This time you see two alert messages, and if you view the source you can see: <script>alert('foo');alert('bar');</script> You can see that the URL variable is being included directly in the page source. Now try going to the URL "index.php?msg=one moment');location.href=(' and observe what happens. This is known as a reflected cross site scripting vulnerability, since the victim must supply specific parameters to the application to trigger the attack (as opposed to a persistent cross site scripting
5 vulnerability where the script is permanently stored in the site, usually in the database back end). Now, this may seem innocuous enough, but lets take the attack one step forward and URL encode the entire query string. To do this we simply craft the URL using the hexidecimal values for each character that the browser will properly interpret, but which a user won't be able to understand. Try going to the URL: index.php?msg=%27%29%3b%6c%6f%63%61%74%69%6f%6e%2e%68%72%65%66%3d %28%27%68%74%74%70%3a%2f%2f%77%77%77%2e%73%61%73%2e%75%70%65%6e%6e%2e%65%64%75 Notice what happened? Now, an end user certainly won't understand what this URL is up to, but you can clearly see the hidden redirect. What if instead of the University of Pennsylvania web site this redirect pointed to a malicious phishing site that harvested usernames and passwords then redirected the user right back to the URL " confirmed, pleas log in". Many users would never notice they had ever visited the phishing page. This type of error could be exploited to harvest usernames and passwords from our application by sending an to users that said the user needed to log into the site using the above URL to confirm their account. This example clearly demonstrates that a vulnerability exists that might be overlooked by a developer. After all, who cares if a user could craft the JavaScript alert on the index page? Obviously a clever attacker would care very much and could exploit this subtle flaw to their advantage. How can this attack be prevented? The easiest way is to enforce that the application behaves exactly as it was intended. The actual PHP code used reads: if ($_GET["msg"]) { $msg = $_GET["msg"]; echo "<! JavaScript error messages >\n<script>alert('$msg');</script>\n\n"; } Now, if the code was altered so that it read: if ($_GET["msg"]) { $msg = urlencode($_get["msg"]); echo "<! JavaScript error messages >\n<script>alert('$msg');</script>\n\n"; } The message string could be altered, but it would never affect how the application functioned. In essence we want to restrict the URL variable from escaping out of the single quotes in the alert. It is tempting to simply do a string replace and replace all single quotes with an escaped single quote, so that the URL:?msg='alert);alert('foo was converted into the string:?msg=\'alert;alert(\'foo
6 which would effectively foil this attack. However, this approach fails if the attacker enters the URL:?msg=\'alert);alert(\'foo because escaping the single quote converts the string into the value:?msg=\\'alert);alert(\\'foo which in fact escapes the back slash, rather than the single quote. Trying to plan for variances in URL crafting will ultimately fail. The only safe way to enforce the parameter is correctly interpreted is to use PHP's native functionality (rather than "rolling your own" solution). See if you can find other cross site scripting attacks in the site. Try to only use XSS attacks that will pop up Javascript alerts since these will be minimally invasive to the actual functionality of the site. Once you realize that a XSS attack is possible you can begin to imagine the possibilities. One particularly evil XSS attack is to inject code (Javascript or otherwise) that actually includes an iframe into the page. If the iframe is merely 1 pixel by 1 pixel it is invisible to the user, but could allow new content to be included in the page. There are several browser attacks that can be performed using the iframe, not the least of which could be to prompt the user to download and execute malicious code. The possibilities are endless.
7 SQL Injection Vulnerabilities SQL injection is probably one of the more dangerous attack vectors created by improper input validation. Ideally, web applications collect data, then construct queries which are then submitted to a back end database. Databases allow for dynamic collection and manipulation of data by a web application and are an increasingly common component for web applications. In order to understand SQL injection we'll examine some SQL injection vulnerabilities in PHP and MySQL based web applications. We'll begin by examining a simply web application and the code that powers it. Let us say we have a blogging application. The code is fairly simple. The front page shows a listing of recent blog posts, with links that users can click through to view individual blog posts. The blog posts are all stored in a MySQL database and are identified by a unique id column. Let's assume the SQL table that powers the blog post looks like the following: Field Type Null Key Default Extra blog_id int(11) NO PRI NULL auto_increment blog_title varchar(255) YES NULL blog_body varchar(255) YES NULL user_id int(11) NO This is a pretty simple structure. Now, let's examine the code that displays an individual blog post (the code that executes when someone clicks a link to the post from the application front page). As you can see, this code looks for an id variable from the URL (a GET variable) and builds a SQL query with that data. Assuming we get the number 12 from the URL (i.e. a link of the structure sitename.tld/view_blog_post.php?id=21) the SQL the PHP would generate would be: SELECT blog.*, user.user_name FROM blog, user WHERE blog.user_id = user.user_id AND blog_id = 21
8 This is perfectly valid SQL and will execute properly. The trouble with the query is that users can manipulate the variable to produce other effects. For instance, if the user modified the variable so that instead of '21' the id they passed in was 21 UNION select user_id, user_name, user_password, NULL, NULL from user the constructed SQL query would be quite different. Instead of the innocuous SQL above, it would be: select blog.*, user.user_name from blog, user where blog.user_id = user.user_id and blog_id = 21 UNION select user_id, user_name, user_password, NULL, NULL from user which results in the following output: blog_id blog_title blog_body user_id user_name admin 40f4c edd677fd b3f0 NULL NULL It's worth noting that this output is caused by the fact that there is no blog_id 21 (otherwise the data from the user columns would be concatenated at the end of the blog data) and also that the passwords are not stored in plain text (these passwords actually the MD5 hash of the original password). There are a multitude of ways that attackers can manipulate input in SQL statements to reveal all sorts of information. PHP/MySQL web applications benefit from one major advantage against SQL injections. Many SQL injection attacks revolve around injecting a semi-colon, which is a statement termination character, and then appending an entirely new statement, often overriding the output of the original statement. Luckily PHP/MySQL does not support this query stacking and only one SQL statement can be issued in a query using PHP's mysql_query() function. This forces attackers to be slightly more clever when constructing their malicious SQL statements.
9 Finding SQL Injection Vulnerabilities The most difficult thing about a SQL injection attack is finding a vulnerability. Pulling off a successful SQL injection requires some precise information about the type of database, the database scheme, and even table structures. Finding this information can be quite difficult. Of course, one could always just attempt blind guessing, but this isn't very effective. Fortunately many developers unwittingly provide mechanisms for an attacker to reconnoiter an application for SQL injection attacks. It is quite common for developers to include debugging messages when SQL queries fail. This is completely unnecessary since the errors are useless to an end user and only help to aid an attacker in mapping the data structures. Ideally error messages should be logged and a helpful message should be displayed to the user that indicates whom to contact and perhaps even alerts a developer to the fact that an error log has been produce. All to commonly, however, you will find PHP that looks something like: if (! $result = mysql_query($query)) { echo "Problem with query: $query<hr/>"; die(mysql_error()); } Not only will this expose the error message, it will also expose the query that caused the error. This gives a nice blueprint to an attacker as to the layout of an application. In the test application all the error messages are constructed using this poor reporting. You can trip a SQL error by attempting to log in using a username with a single quote in the name. This will cause a SQL injection that will throw an error. For instance attempting to log in using the username 'foo (leave the password field blank) will cause the following error to be displayed: Problem with query: select user_password from user where user_name = ''foo' and user_password = 'd41d8cd98f00b204e ecf8427e' You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'foo' and user_password = 'd41d8cd98f00b204e ecf8427e'' at line 1 This error message provides a real wealth of information. Let's start by analyzing what caused the error. It's easy to spot the orphaned single quote in the query at the "name = ''foo'" portion. The extra quote in the name is causing malformed SQL. This can be worked around with some cleverness, but proves that SQL injection is possible. The second error message is perhaps the most helpful in identifying the exact source of the error message. The second interesting tidbit is the password part of the query. Instead of passing a blank entry there is a 32 character string. This is pretty much a dead giveaway that the application is, quite wisely, storing hashes of passwords in the database. You can guess that the value inserted by a user is hashed and that hash value is compared to the value in the database. Despite the use of a secured password we can actually use the SQL injection to bypass the authentication of the test application. Looking at the blog posts it seems like there is a user named 'admin'. We can try to authenticate as admin by exploiting the logic in the user authentication query. Because we can manipulate the query with SQL injection we can introduce new parameters to the query. See if you can figure out how to do this on your own.
10 Exploiting the Vulnerability Once you've tried a few combinations we can look at one of the several ways that we can end run this authentication. The authentication SQL query is structured as such: select user_password from user where user_name = '[value]' and user_password = '[value]' Because SQL is evaluated left to right with respect to AND and OR, what if we threw an OR statement into the query that always evaluated as true. For instance, what if we manipulate the query so that it ends up being: select user_password from user where user_name = 'admin' AND 1=1 OR user_name='admin' and user_password = '[hash value]' We can do this by logging in using the username: admin' AND 1=1 OR user_name='admin Go ahead and try this out and notice how the site actually lets you log in as the administrator. This is because the SQL query ends up selecting the password if the name is 'admin' and 1=1 (which it always does) OR if the name is 'admin' and the password is whatever hash we got. You can see the second part of the query fails, but the first part succeeds, and because: IF TRUE OR FALSE = TRUE The query returns the requested value. You can also see how a good understanding of SQL helps an attacker with this sort of attack. There are several other SQL injection possibilities throughout the test site. Because query stacking is illegal using the mysql_query() function the damage from SQL injection is limited to the type of query being executed. Thus, an INSERT statement could be manipulated to insert new or malformed data. More dangerous would be an UPDATE statement. In fact, there is an UPDATE statement available in the test application. If you log in and create a new user account you can update your account name and password. You can perform a SQL injection attack to update the admin password, which would cause a denial of service for the real admin and elevate your own privilege to that of admin. The most dangerous type of SQL injection would occur with a DELETE statement, but there aren't any of those in this particular test application.
11 Protecting Against SQL Injection The easiest way to protect against SQL injection attacks is to sanitize data as it is passed in by a user, as well as sanitizing any data that is pulled out of the database. PHP has several amazingly useful functions for this purpose. The most effective is mysql_real_escape_string(). Using this will prevent any SQL injection by escaping single quotes properly. Using strict data typing can also help. Functions like intval() can be used to translate user input into strict data types. This prevents bad data from even making it into the query. Other functions such as htmlentities(), htmlspecialchars(), and even urlencode() can be used to craft safer data for display. This can prevent problems down the road, protecting against threats such as XSS. The bottom line is that you should never trust user input. Never trust any input from the client. Even hidden form fields can be manipulated, and Javascript checks can easily be evaded (just check out the Tamper Data extension for Firefox to see how easy this is). You have to be sure you sanitize data on the server side before passing it to a SQL query. Even once data is in the database, it should be handled with care when extracted and displayed. Using prepared statements and libraries like MDB2 can greatly enhance your application security. Using a central library for all SQL queries can insure that each query is properly sanitized before being executed (rather than trying to keep track of and secure queries all over your code). Using object oriented code can also help, forcing variables to be passed into objects before being passed to SQL queries provides further opportunities to sanitize your data.
12 File Inclusion Vulnerabilities File inclusion vulnerabilities are a similar sort of beast to SQL injections. In a file inclusion vulnerability an attacker seeks to manipulate a string that is constructed with user supplied input. Let's take the following PHP code example, which is intended to include a story in the body of a page: As you can see here, the code attempts to get the story variable from the URL and then include the appropriate page. This would likely be called when a viewer clicked on a link that included a sub page, for instance: This becomes a problem, however, if a malicious user includes a link to a file on the filesystem, or even on a different filesystem. If the user tried to mangle the variable to link to a local file they might expose sensitive data from the filesystem:
13 An attacker can take this one step farther and actually include remote files which could include PHP that is actually executed on the local filesystem. To do this the attacker hosts a text file on a remote server, and calls it via a URL variable. For instance, if the attacker hosted the following file on the remote system: and called it using the same method above the output would be: It is interesting to note that if the evil_include file hosted on the remote system has a PHP file extension it will be executed on the remote system. It is imperative that the remote file have the.txt file extension in order to be executed on the local system. There are some mitigation strategies that are commonly employed to prevent file inclusion. Unfortunately many of these don't work as the developer expects. Suppose the following PHP code is used instead of that listed above:
14 The developer in this instance appends the file extension onto the file name. This will prevent attacks that call local files or remote non-php files, or so you would think. Unfortunately, because PHP is written in C, it uses null bytes as string terminators. So any string that has a null byte in it will only be interpreted up until the null byte. Thus, the statement: $filename = 'some_file_name[null byte].php'; would only resolve as 'some_file_name' when interpreted in a command such as: include($filename); The null byte character is trivially easy to include in a URL, as the character sequence %00. Thus, if an attacker includes the %00 in their malicious input, they can end run the developers attempts to include the.php file extension. For instance, an attacker calling the PHP code above that includes the.php file extension can overcome it like so:
15 Note that any remote file inclusion requires that certain parameters be set in the php.ini file (usually found in /etc/php.ini). The following must be set: ; Whether to allow include/require to open URLs (like or ftp://) as files. allow_url_include = On If allow_url_include is set to Off then remote file include attacks of this sort will not work. * Suhosin will defeat this attack! [Tue Feb 03 15:22: ] [error] [client ] ALERT Include filename ('../ is an URL that is not allowed (attacker ' ', file '/var/www/html/test.php', line 8)
16 Other Input Manipulations Authentication Bypass Another common information manipulation attack is directed at authentication bypass. It is not uncommon for dynamic PHP web applications to have an administration site or have content restricted to authenticated users. Attackers will often try to probe the authentication mechanisms that protect these resources in order to bypass them. One common way to authenticate users is via cookies. Cookies can be a wonderful way to track session state, but many developers do not consider that cookie values are user supplied data and are subject to manipulation, and thus must be sanitized before utilization. Consider the following snippit of PHP that is included on an administrative index page: You can easily see how if a malicious user manipulated their cookie values they could perform SQL injection to entirely bypass the authentication mechanism. This type of problem crops up in many forms. Common problems are simply checking for the existence of a cookie (a user can create a cookie without application input), or checking that a cookie value is set (a user can set and adjust cookie values at will). Using cookie values in SQL carries all the same risk as using any type of user supplied data.
17 Information Leaking Information leaking is usually a condition introduce by misconfiguration rather than programming error. Some common forms of information leaking include improperly setting file permissions on files, or placing sensitive information in files that are accessible via the web. For instance: While this is just one means of information disclosure, a far more common flaw is leaving directory indexing on. This can be especially damaging if it allows an attacker to browse the filesystem and find files that may include configuration details, or even source code. Attackers will often search for source code, or test or backup scripts that have changed file extensions that would allow the attacker to browse the source code. Finding this sort of information can allow an attacker to craft targeted attacks that are much more effective.
C1: Define Security Requirements
OWASP Top 10 Proactive Controls IEEE Top 10 Software Security Design Flaws OWASP Top 10 Vulnerabilities Mitigated OWASP Mobile Top 10 Vulnerabilities Mitigated C1: Define Security Requirements A security
More informationWEB SECURITY WORKSHOP TEXSAW Presented by Solomon Boyd and Jiayang Wang
WEB SECURITY WORKSHOP TEXSAW 2014 Presented by Solomon Boyd and Jiayang Wang Introduction and Background Targets Web Applications Web Pages Databases Goals Steal data Gain access to system Bypass authentication
More informationWeb insecurity Security strategies General security Listing of server-side risks Language specific security. Web Security.
Web Security Web Programming Uta Priss ZELL, Ostfalia University 2013 Web Programming Web Security Slide 1/25 Outline Web insecurity Security strategies General security Listing of server-side risks Language
More informationWeb Attacks Lab. 35 Points Group Lab Due Date: Lesson 16
CS482 SQL and XSS Attack Lab AY172 1 Web Attacks Lab 35 Points Group Lab Due Date: Lesson 16 Derived from c 2006-2014 Wenliang Du, Syracuse University. Do not redistribute with explicit consent from MAJ
More informationCNIT 129S: Securing Web Applications. Ch 10: Attacking Back-End Components
CNIT 129S: Securing Web Applications Ch 10: Attacking Back-End Components Injecting OS Commands Web server platforms often have APIs To access the filesystem, interface with other processes, and for network
More informationCNIT 129S: Securing Web Applications. Ch 12: Attacking Users: Cross-Site Scripting (XSS) Part 2
CNIT 129S: Securing Web Applications Ch 12: Attacking Users: Cross-Site Scripting (XSS) Part 2 Finding and Exploiting XSS Vunerabilities Basic Approach Inject this string into every parameter on every
More informationCSE361 Web Security. Attacks against the server-side of web applications. Nick Nikiforakis
CSE361 Web Security Attacks against the server-side of web applications Nick Nikiforakis nick@cs.stonybrook.edu Threat model In these scenarios: The server is benign The client is malicious The client
More informationExcerpts of Web Application Security focusing on Data Validation. adapted for F.I.S.T. 2004, Frankfurt
Excerpts of Web Application Security focusing on Data Validation adapted for F.I.S.T. 2004, Frankfurt by fs Purpose of this course: 1. Relate to WA s and get a basic understanding of them 2. Understand
More informationAttacks Against Websites. Tom Chothia Computer Security, Lecture 11
Attacks Against Websites Tom Chothia Computer Security, Lecture 11 A typical web set up TLS Server HTTP GET cookie Client HTML HTTP file HTML PHP process Display PHP SQL Typical Web Setup HTTP website:
More informationNET 311 INFORMATION SECURITY
NET 311 INFORMATION SECURITY Networks and Communication Department Lec12: Software Security / Vulnerabilities lecture contents: o Vulnerabilities in programs Buffer Overflow Cross-site Scripting (XSS)
More informationSECURE CODING ESSENTIALS
SECURE CODING ESSENTIALS DEFENDING YOUR WEB APPLICATION AGAINST CYBER ATTACKS ROB AUGUSTINUS 30 MARCH 2017 AGENDA Intro - A.S. Watson and Me Why this Presentation? Security Architecture Secure Code Design
More informationJohn Coggeshall Copyright 2006, Zend Technologies Inc.
PHP Security Basics John Coggeshall Copyright 2006, Zend Technologies Inc. Welcome! Welcome to PHP Security Basics Who am I: John Coggeshall Lead, North American Professional Services PHP 5 Core Contributor
More informationW e b A p p l i c a t i o n S e c u r i t y : T h e D e v i l i s i n t h e D e t a i l s
W e b A p p l i c a t i o n S e c u r i t y : T h e D e v i l i s i n t h e D e t a i l s Session I of III JD Nir, Security Analyst Why is this important? ISE Proprietary Agenda About ISE Web Applications
More informationWeb Application Security. Philippe Bogaerts
Web Application Security Philippe Bogaerts OWASP TOP 10 3 Aim of the OWASP Top 10 educate developers, designers, architects and organizations about the consequences of the most common web application security
More informationApplication vulnerabilities and defences
Application vulnerabilities and defences In this lecture We examine the following : SQL injection XSS CSRF SQL injection SQL injection is a basic attack used to either gain unauthorized access to a database
More informationWeb Application & Web Server Vulnerabilities Assessment Pankaj Sharma
Web Application & Web Server Vulnerabilities Assessment Pankaj Sharma Indian Computer Emergency Response Team ( CERT - IN ) Department Of Information Technology 1 Agenda Introduction What are Web Applications?
More informationCopyright
1 Security Test EXTRA Workshop : ANSWER THESE QUESTIONS 1. What do you consider to be the biggest security issues with mobile phones? 2. How seriously are consumers and companies taking these threats?
More informationEasyCrypt passes an independent security audit
July 24, 2017 EasyCrypt passes an independent security audit EasyCrypt, a Swiss-based email encryption and privacy service, announced that it has passed an independent security audit. The audit was sponsored
More informationWeb Application Security Evaluation
Web Application Security Evaluation Jack Wilson Abertay University White Paper BSc Ethical Hacking 2016/2017 TABLE OF CONTENTS 1. Introduction..3 2. Vulnerabilities Discovered and Countermeasures...4 2.1
More informationWebGoat Lab session overview
WebGoat Lab session overview Initial Setup Virtual Machine Tamper Data Web Goat Basics HTTP Basics Sniffing Web server attacks SQL Injection XSS INITIAL SETUP Tamper Data Hold alt to reveal the menu in
More informationApplication Security Introduction. Tara Gu IBM Product Security Incident Response Team
Application Security Introduction Tara Gu IBM Product Security Incident Response Team About Me - Tara Gu - tara.weiqing@gmail.com - Duke B.S.E Biomedical Engineering - Duke M.Eng Computer Engineering -
More informationApplication Security through a Hacker s Eyes James Walden Northern Kentucky University
Application Security through a Hacker s Eyes James Walden Northern Kentucky University waldenj@nku.edu Why Do Hackers Target Web Apps? Attack Surface A system s attack surface consists of all of the ways
More informationComputer Security 3e. Dieter Gollmann. Chapter 18: 1
Computer Security 3e Dieter Gollmann www.wiley.com/college/gollmann Chapter 18: 1 Chapter 18: Web Security Chapter 18: 2 Web 1.0 browser HTTP request HTML + CSS data web server backend systems Chapter
More informationThis slide shows the OWASP Top 10 Web Application Security Risks of 2017, which is a list of the currently most dangerous web vulnerabilities in
1 This slide shows the OWASP Top 10 Web Application Security Risks of 2017, which is a list of the currently most dangerous web vulnerabilities in terms of prevalence (how much the vulnerability is widespread),
More informationJacksonville Linux User Group Presenter: Travis Phillips Date: 02/20/2013
Jacksonville Linux User Group Presenter: Travis Phillips Date: 02/20/2013 Welcome Back! A Quick Recap of the Last Presentation: Overview of web technologies. What it is. How it works. Why it s attractive
More information1 About Web Security. What is application security? So what can happen? see [?]
1 About Web Security What is application security? see [?] So what can happen? 1 taken from [?] first half of 2013 Let s focus on application security risks Risk = vulnerability + impact New App: http://www-03.ibm.com/security/xforce/xfisi
More informationAttacks Against Websites 3 The OWASP Top 10. Tom Chothia Computer Security, Lecture 14
Attacks Against Websites 3 The OWASP Top 10 Tom Chothia Computer Security, Lecture 14 OWASP top 10. The Open Web Application Security Project Open public effort to improve web security: Many useful documents.
More informationWeb Vulnerabilities. And The People Who Love Them
Web Vulnerabilities And The People Who Love Them Me Tom Hudson Technical Trainer at Sky Betting & Gaming TomNomNom online Occasional bug hunter Lover of analogies Lover of questions Insecure Direct Object
More informationPerslink Security. Perslink Security. Eleonora Petridou Pascal Cuylaerts. System And Network Engineering University of Amsterdam.
Eleonora Petridou Pascal Cuylaerts System And Network Engineering University of Amsterdam June 30, 2011 Outline Research question About Perslink Approach Manual inspection Automated tests Vulnerabilities
More information3. Apache Server Vulnerability Identification and Analysis
1. Target Identification The pentester uses netdiscover to identify the target: root@kali:~# netdiscover -r 192.168.0.0/24 Target: 192.168.0.48 (Cadmus Computer Systems) Note: the victim IP address changes
More informationRuby on Rails Secure Coding Recommendations
Introduction Altius IT s list of Ruby on Rails Secure Coding Recommendations is based upon security best practices. This list may not be complete and Altius IT recommends this list be augmented with additional
More informationEthical Hacking and Countermeasures: Web Applications, Second Edition. Chapter 3 Web Application Vulnerabilities
Ethical Hacking and Countermeasures: Web Chapter 3 Web Application Vulnerabilities Objectives After completing this chapter, you should be able to: Understand the architecture of Web applications Understand
More informationSolution of Exercise Sheet 5
Foundations of Cybersecurity (Winter 16/17) Prof. Dr. Michael Backes CISPA / Saarland University saarland university computer science Solution of Exercise Sheet 5 1 SQL Injection Consider a website foo.com
More informationANZTB SIGIST May 2011 Perth OWASP How minor vulnerabilities can do very bad things. OWASP Wednesday 25 th May The OWASP Foundation
ANZTB SIGIST May 2011 Perth OWASP How minor vulnerabilities can do very bad things Christian Frichot / David Taylor (Some of) Perth OWASP s Chapter Leads OWASP Wednesday 25 th May 2011 Copyright The OWASP
More informationEvaluating the Security Risks of Static vs. Dynamic Websites
Evaluating the Security Risks of Static vs. Dynamic Websites Ballard Blair Comp 116: Introduction to Computer Security Professor Ming Chow December 13, 2017 Abstract This research paper aims to outline
More information(System) Integrity attacks System Abuse, Malicious File upload, SQL Injection
Pattern Recognition and Applications Lab (System) Integrity attacks System Abuse, Malicious File upload, SQL Injection Igino Corona igino.corona (at) diee.unica.it Computer Security April 9, 2018 Department
More informationGUI based and very easy to use, no security expertise required. Reporting in both HTML and RTF formats - Click here to view the sample report.
Report on IRONWASP Software Product: IronWASP Description of the Product: IronWASP (Iron Web application Advanced Security testing Platform) is an open source system for web application vulnerability testing.
More informationDEFENSIVE PROGRAMMING. Lecture for EDA 263 Magnus Almgren Department of Computer Science and Engineering Chalmers University of Technology
DEFENSIVE PROGRAMMING Lecture for EDA 263 Magnus Almgren Department of Computer Science and Engineering Chalmers University of Technology Traditional Programming When writing a program, programmers typically
More informationRBS NetGain Enterprise Manager Multiple Vulnerabilities of 11
RBS-2018-004 NetGain Enterprise Manager Multiple Vulnerabilities 2018-03-22 1 of 11 Table of Contents Vendor / Product Information 3 Vulnerable Program Details 3 Credits 3 Impact 3 Vulnerability Details
More informationLecture 7: Web hacking 3, SQL injection, Xpath injection, Server side template injection, File inclusion
IN5290 Ethical Hacking Lecture 7: Web hacking 3, SQL injection, Xpath injection, Server side template injection, File inclusion Universitetet i Oslo Laszlo Erdödi Lecture Overview What is SQL injection
More informationIS 2150 / TEL 2810 Introduction to Security
IS 2150 / TEL 2810 Introduction to Security James Joshi Professor, SIS Lecture 15 April 20, 2016 SQL Injection Cross-Site Scripting 1 Goals Overview SQL Injection Attacks Cross-Site Scripting Attacks Some
More informationDaniel Pittman October 17, 2011
Daniel Pittman October 17, 2011 SELECT target-list FROM relation-list WHERE qualification target-list A list of attributes of relations in relation-list relation-list A list of relation names qualification
More informationBIG-IP Application Security Manager : Attack and Bot Signatures. Version 13.0
BIG-IP Application Security Manager : Attack and Bot Signatures Version 13.0 Table of Contents Table of Contents Assigning Attack Signatures to Security Policies...5 About attack signatures...5 About
More informationWEB APPLICATION SCANNERS. Evaluating Past the Base Case
WEB APPLICATION SCANNERS Evaluating Past the Base Case GREG OSE PATRICK TOOMEY Presenter Intros Overview An overview of web application scanners Why is it hard to evaluate scanner efficacy? Prior Work
More informationWeb Security. Jace Baker, Nick Ramos, Hugo Espiritu, Andrew Le
Web Security Jace Baker, Nick Ramos, Hugo Espiritu, Andrew Le Topics Web Architecture Parameter Tampering Local File Inclusion SQL Injection XSS Web Architecture Web Request Structure Web Request Structure
More informationProject 2: Web Security
EECS 388 September 30, 2016 Intro to Computer Security Project 2: Web Security Project 2: Web Security This project is due on Thursday, October 13 at 6 p.m. and counts for 8% of your course grade. Late
More informationFinding Vulnerabilities in Web Applications
Finding Vulnerabilities in Web Applications Christopher Kruegel, Technical University Vienna Evolving Networks, Evolving Threats The past few years have witnessed a significant increase in the number of
More informationAdvanced Web Technology 10) XSS, CSRF and SQL Injection
Berner Fachhochschule, Technik und Informatik Advanced Web Technology 10) XSS, CSRF and SQL Injection Dr. E. Benoist Fall Semester 2010/2011 1 Table of Contents Cross Site Request Forgery - CSRF Presentation
More informationAssignment 6: Web Security
COS 432 November 20, 2017 Information Security Assignment 6: Web Security Assignment 6: Web Security This project is due on Monday, December 4 at 11:59 p.m.. Late submissions will be penalized by 10% per
More informationshortcut Tap into learning NOW! Visit for a complete list of Short Cuts. Your Short Cut to Knowledge
shortcut Your Short Cut to Knowledge The following is an excerpt from a Short Cut published by one of the Pearson Education imprints. Short Cuts are short, concise, PDF documents designed specifically
More informationP2_L12 Web Security Page 1
P2_L12 Web Security Page 1 Reference: Computer Security by Stallings and Brown, Chapter (not specified) The web is an extension of our computing environment, because most of our daily tasks involve interaction
More informationYour Turn to Hack the OWASP Top 10!
OWASP Top 10 Web Application Security Risks Your Turn to Hack OWASP Top 10 using Mutillidae Born to Be Hacked Metasploit in VMWare Page 1 https://www.owasp.org/index.php/main_page The Open Web Application
More informationVULNERABILITIES IN 2017 CODE ANALYSIS WEB APPLICATION AUTOMATED
AUTOMATED CODE ANALYSIS WEB APPLICATION VULNERABILITIES IN 2017 CONTENTS Introduction...3 Testing methods and classification...3 1. Executive summary...4 2. How PT AI works...4 2.1. Verifying vulnerabilities...5
More informationExploiting and Defending: Common Web Application Vulnerabilities
Exploiting and Defending: Common Web Application Vulnerabilities Introduction: Steve Kosten Principal Security Consultant SANS Instructor Denver OWASP Chapter Lead Certifications CISSP, GWAPT, GSSP-Java,
More informationCSE 127 Computer Security
CSE 127 Computer Security Fall 2015 Web Security I: SQL injection Stefan Savage The Web creates new problems Web sites are programs Partially implemented in browser» Javascript, Java, Flash Partially implemented
More informationAvoiding Web Application Flaws In Embedded Devices. Jake Edge LWN.net URL for slides:
Avoiding Web Application Flaws In Embedded Devices Jake Edge LWN.net jake@lwn.net URL for slides: http://lwn.net/talks/elce2008 Overview Examples embedded devices gone bad Brief introduction to HTTP Authentication
More information2/16/18. CYSE 411/AIT 681 Secure Software Engineering. Secure Coding. The Web. Topic #11. Web Security. Instructor: Dr. Kun Sun
CYSE 411/AIT 681 Secure Software Engineering Topic #11. Web Security Instructor: Dr. Kun Sun Secure Coding String management Pointer Subterfuge Dynamic memory management Integer security Formatted output
More informationSQL Injection Attack: Detection in a Web Application Environment
SQL Injection Attack: Detection in a Web Application Environment Table of Contents 1 Foreword... 1 2 Background... 2 2.1 Web Application Environment... 2 2.2 SQL Attack Overview... 2 2.3 Applications Open
More informationSecurity Penetration Test of HIE Portal for A CUSTOMER IMPLEMENTION. Services provided to: [LOGO(s) of company providing service to]
Security Penetration Test of HIE Portal for A CUSTOMER IMPLEMENTION Services provided to: [LOGO(s) of company providing service to] Version V1.0 V1 February 13 th, 2014 Prepared By: Denis Calderone TBG
More informationCombating Common Web App Authentication Threats
Security PS Combating Common Web App Authentication Threats Bruce K. Marshall, CISSP, NSA-IAM Senior Security Consultant bmarshall@securityps.com Key Topics Key Presentation Topics Understanding Web App
More informationDreamFactory Security Guide
DreamFactory Security Guide This white paper is designed to provide security information about DreamFactory. The sections below discuss the inherently secure characteristics of the platform and the explicit
More informationPHP Security. Kevin Schroeder Zend Technologies. Copyright 2007, Zend Technologies Inc.
PHP Security Kevin Schroeder Zend Technologies Copyright 2007, Zend Technologies Inc. Disclaimer Do not use anything you learn here for nefarious purposes Why Program Securely? Your job/reputation depends
More informationComputer Security Coursework Exercise CW1 Web Server and Application Security
Computer Security Coursework Exercise CW1 Web Server and Application Security In this coursework exercise we will guide you through an attack against a vulnerable machine. You will take the role of Mallet
More informationWeb Application Attacks
Web Application Attacks What can an attacker do and just how hard is it? By Damon P. Cortesi IOActive, Inc. Comprehensive Computer Security Services www.ioactive.com cortesi:~
More informationCSCD 303 Essential Computer Security Fall 2018
CSCD 303 Essential Computer Security Fall 2018 Lecture 17 XSS, SQL Injection and CRSF Reading: See links - End of Slides Overview Idea of XSS, CSRF and SQL injection is to violate security of Web Browser/Server
More informationJackson State University Department of Computer Science CSC / Advanced Information Security Spring 2013 Lab Project # 3
Jackson State University Department of Computer Science CSC 439-01/539-02 Advanced Information Security Spring 2013 Lab Project # 3 Use of CAPTCHA (Image Identification Strategy) to Prevent XSRF Attacks
More informationAndrew Muller, Canberra Managing Director, Ionize, Canberra The challenges of Security Testing. Security Testing. Taming the Wild West
Andrew Muller, Canberra Managing Director, Ionize, Canberra The challenges of Security Testing Advancing Expertise in Security Testing Taming the Wild West Canberra, Australia 1 Who is this guy? Andrew
More informationWeb Security 2 https://www.xkcd.com/177/ http://xkcd.com/1323/ Encryption basics Plaintext message key secret Encryp)on Func)on Ciphertext Insecure network Decryp)on Func)on Curses! Foiled again! key Plaintext
More informationCS 161 Computer Security
Nick Weaver Fall 2018 CS 161 Computer Security Homework 3 Due: Friday, 19 October 2018, at 11:59pm Instructions. This homework is due Friday, 19 October 2018, at 11:59pm. No late homeworks will be accepted
More informationAn analysis of security in a web application development process
An analysis of security in a web application development process Florent Gontharet Ethical Hacking University of Abertay Dundee MSc Ethical Hacking 2015 Table of Contents Abstract...2 Introduction...3
More informationTop 10 Application Security Vulnerabilities in Web.config Files Part One
Top 10 Application Security Vulnerabilities in Web.config Files Part One By Bryan Sullivan These days, the biggest threat to an organization s network security comes from its public Web site and the Web-based
More informationComputer Forensics: Investigating Network Intrusions and Cyber Crime, 2nd Edition. Chapter 3 Investigating Web Attacks
Computer Forensics: Investigating Network Intrusions and Cyber Crime, 2nd Edition Chapter 3 Investigating Web Attacks Objectives After completing this chapter, you should be able to: Recognize the indications
More informationSecure Coding and Code Review. Berlin : 2012
Secure Coding and Code Review Berlin : 2012 Outline Overview of top vulnerabilities Code review practice Secure design / writing secure code Write some secure code Review a volunteer's code Top Problems
More informationCSCD 303 Essential Computer Security Fall 2017
CSCD 303 Essential Computer Security Fall 2017 Lecture 18a XSS, SQL Injection and CRSF Reading: See links - End of Slides Overview Idea of XSS, CSRF and SQL injection is to violate the security of the
More informationBank Infrastructure - Video - 1
Bank Infrastructure - 1 05/09/2017 Threats Threat Source Risk Status Date Created Account Footprinting Web Browser Targeted Malware Web Browser Man in the browser Web Browser Identity Spoofing - Impersonation
More informationWEB SECURITY: XSS & CSRF
WEB SECURITY: XSS & CSRF CMSC 414 FEB 22 2018 Cross-Site Request Forgery (CSRF) URLs with side-effects http://bank.com/transfer.cgi?amt=9999&to=attacker GET requests should have no side-effects, but often
More informationWeb Application Penetration Testing
Web Application Penetration Testing COURSE BROCHURE & SYLLABUS Course Overview Web Application penetration Testing (WAPT) is the Security testing techniques for vulnerabilities or security holes in corporate
More informationSpecialized Security Services, Inc. REDUCE RISK WITH CONFIDENCE. s3security.com
Specialized Security Services, Inc. REDUCE RISK WITH CONFIDENCE s3security.com Security Professional Services S3 offers security services through its Security Professional Services (SPS) group, the security-consulting
More informationSlides adopted from Laurie Williams. OWASP Top Ten. John Slankas
Slides adopted from Laurie Williams OWASP Top Ten John Slankas jbslanka@ncsu.edu Agenda Overview of the Top 10 A1 Injection A2 Broken Authentication and Session Management A3 Cross-Site Scripting A4 Broken
More informationContents. SSL-Based Services: HTTPS and FTPS 2. Generating A Certificate 2. Creating A Self-Signed Certificate 3. Obtaining A Signed Certificate 4
Contents SSL-Based Services: HTTPS and FTPS 2 Generating A Certificate 2 Creating A Self-Signed Certificate 3 Obtaining A Signed Certificate 4 Enabling Secure Services 5 SSL/TLS Security Level 5 A Note
More informationFeaturing. and. Göteborg. Ulf Larson Thursday, October 24, 13
Featuring and Göteborg OWASP top ten 2013 Based on risk data from eight firms that specialize in application security, This data spans over 500,000 vulnerabilities across hundreds of organizations and
More informationSurvey of Cyber Moving Targets. Presented By Sharani Sankaran
Survey of Cyber Moving Targets Presented By Sharani Sankaran Moving Target Defense A cyber moving target technique refers to any technique that attempts to defend a system and increase the complexity of
More informationWeb Security II. Slides from M. Hicks, University of Maryland
Web Security II Slides from M. Hicks, University of Maryland Recall: Putting State to HTTP Web application maintains ephemeral state Server processing often produces intermediate results; not long-lived
More informationCSE361 Web Security. Attacks against the client-side of web applications. Nick Nikiforakis
CSE361 Web Security Attacks against the client-side of web applications Nick Nikiforakis nick@cs.stonybrook.edu Despite the same origin policy Many things can go wrong at the client-side of a web application
More informationINF3700 Informasjonsteknologi og samfunn. Application Security. Audun Jøsang University of Oslo Spring 2015
INF3700 Informasjonsteknologi og samfunn Application Security Audun Jøsang University of Oslo Spring 2015 Outline Application Security Malicious Software Attacks on applications 2 Malicious Software 3
More informationCS 356 Operating System Security. Fall 2013
CS 356 Operating System Security Fall 2013 Review Chapter 1: Basic Concepts and Terminology Chapter 2: Basic Cryptographic Tools Chapter 3 User Authentication Chapter 4 Access Control Lists Chapter 5 Database
More informationWeb Application Security GVSAGE Theater
Web Application Security GVSAGE Theater B2B Tech Expo Oct 29, 2003 Durkee Consulting www.rd1.net 1 Ralph Durkee SANS Certified Mentor/Instructor SANS GSEC, GCIH, GGSC Network Security and Software Development
More informationInformation Security. Gabriel Lawrence Director, IT Security UCSD
Information Security Gabriel Lawrence Director, IT Security UCSD Director of IT Security, UCSD Three Startups (2 still around!) Sun Microsystems (Consulting and JavaSoftware) Secure Internet Applications
More informationSecurity and Privacy. SWE 432, Fall 2016 Design and Implementation of Software for the Web
Security and Privacy SWE 432, Fall 2016 Design and Implementation of Software for the Web Today Security What is it? Most important types of attacks Privacy For further reading: https://www.owasp.org/index.php/
More informationLecture 3: Web Servers / PHP and Apache. CS 383 Web Development II Monday, January 29, 2018
Lecture 3: Web Servers / PHP and Apache CS 383 Web Development II Monday, January 29, 2018 Server Configuration One of the most common configurations of servers meant for web development is called a LAMP
More informationClient Side Injection on Web Applications
Client Side Injection on Web Applications Author: Milad Khoshdel Blog: https://blog.regux.com Email: miladkhoshdel@gmail.com 1 P a g e Contents INTRODUCTION... 3 HTML Injection Vulnerability... 4 How to
More informationHacking Oracle APEX. Welcome. About
Hacking Oracle APEX!2 About Me Welcome scott@sumnertech.com @sspendol!3!4 About Sumner Technologies Originally Established 2005 Relaunched in 2015 Focused exclusively on Oracle APEX solutions Provide wide
More informationLecture Overview. IN5290 Ethical Hacking. Lecture 4: Web hacking 1, Client side bypass, Tampering data, Brute-forcing
Lecture Overview IN5290 Ethical Hacking Lecture 4: Web hacking 1, Client side bypass, Tampering data, Brute-forcing Summary - how web sites work HTTP protocol Client side server side actions Accessing
More informationANALYSIS OF VARIOUS LEVELS OF PENETRATION BY SQL INJECTION TECHNIQUE THROUGH DVWA
ANALYSIS OF VARIOUS LEVELS OF PENETRATION BY SQL INJECTION TECHNIQUE THROUGH DVWA By Ashish Kumar, Dr. Swapnesh Taterh 1st AIIT, Amity University, Rajasthan. 2nd Asst Prof, AIIT, Amity University, Rajasthan.
More informationA1 (Part 2): Injection SQL Injection
A1 (Part 2): Injection SQL Injection SQL injection is prevalent SQL injection is impactful Why a password manager is a good idea! SQL injection is ironic SQL injection is funny Firewall Firewall Accounts
More informationXSS Homework. 1 Overview. 2 Lab Environment
XSS Homework 1 Overview Cross-site scripting (XSS) is a type of vulnerability commonly found in web applications. This vulnerability makes it possible for attackers to inject malicious code (e.g. JavaScript
More informationProvide you with a quick introduction to web application security Increase you awareness and knowledge of security in general Show you that any
OWASP Top 10 Provide you with a quick introduction to web application security Increase you awareness and knowledge of security in general Show you that any tester can (and should) do security testing
More informationBuilding Trust in the Internet of Things
AN INTEL COMPANY Building Trust in the Internet of Things Developing an End-to-End Security Strategy for IoT Applications WHEN IT MATTERS, IT RUNS ON WIND RIVER EXECUTIVE SUMMARY Recent security breaches
More informationCS 155 Project 2. Overview & Part A
CS 155 Project 2 Overview & Part A Project 2 Web application security Composed of two parts Part A: Attack Part B: Defense Due date: Part A: May 5th (Thu) Part B: May 12th (Thu) Project 2 Ruby-on-Rails
More informationTutorial of SQL Power Injector 1.2
Copyright 2006-2007 Francois Larouche 1 Copyright 2006-2007 Francois Larouche 2 Copyright 2006-2007 Francois Larouche 3 Please follow first the main schema and if you need more details go to their respective
More information