This document provides 12 practical tips for securing web applications against common attacks like cross-site scripting and SQL injection. The tips include using carefully vetted validation code, specifying variable types, whitelisting acceptable characters, limiting input size, canonicalizing input before filtering, filtering all input sources, performing filtering on the server-side, utilizing output encoding, choosing the appropriate encoding for outputs, conducting code reviews, and performing penetration tests. The document aims to help developers avoid mistakes like improper input validation and output filtering.
Application Security Part 1 Threat Defense In Client Server Applications ...Greg Sohl
This presentation grew out of my experience with testing client-server applications (web, disconnected thin client, etc.) for security issues. The knowledge was gained through research and experience. I gave the presentation to the Cedar Rapids .NET User Group (CRineta.org) in 2006.
Sania: Syntactic and Semantic Analysis for Automated Testing against SQL Inje...Yuji Kosuga
With the recent rapid increase in interactive web applications that employ back-end database services, an SQL injection attack has become one of the most serious security threats. The SQL injection attack allows an attacker to access the underlying database, execute arbitrary commands at intent, and receive a dynamically generated output, such as HTML web pages. In this paper, we present our technique, Sania, for detecting SQL injection vulnerabilities in web applications during the development and debugging phases. Sania intercepts the SQL queries between a web application and a database, and automatically generates elaborate attacks according to the syntax and semantics of the potentially vulnerable spots in the SQL queries. In addition, Sania compares the parse trees of the intended SQL query and those resulting after an attack to assess the safety of these spots. We evaluated our technique using real-world web applications and found that our solution is efficient in comparison with a popular web application vulnerabilities scanner. We also found vulnerability in a product that was just about to be released.
Automated Detection of Session Fixation VulnerabilitiesYuji Kosuga
Session fixation is a technique for obtaining the visitor's session identifier (SID) by forcing the visitor to use the SID supplied by the attacker. The attacker who obtains the victim's SID can masquerade as the visitor. In this paper, we propose a technique to automatically detect session fixation vulnerabilities in web applications. Our technique uses attack simulator that executes a real session fixation attack and check whether it is successful or not. In the experiment, our system successfully detected vulnerabilities in our original test cases and in a real world web application.
International Journal of Engineering Research and Applications (IJERA) is an open access online peer reviewed international journal that publishes research and review articles in the fields of Computer Science, Neural Networks, Electrical Engineering, Software Engineering, Information Technology, Mechanical Engineering, Chemical Engineering, Plastic Engineering, Food Technology, Textile Engineering, Nano Technology & science, Power Electronics, Electronics & Communication Engineering, Computational mathematics, Image processing, Civil Engineering, Structural Engineering, Environmental Engineering, VLSI Testing & Low Power VLSI Design etc.
Application Security Part 1 Threat Defense In Client Server Applications ...Greg Sohl
This presentation grew out of my experience with testing client-server applications (web, disconnected thin client, etc.) for security issues. The knowledge was gained through research and experience. I gave the presentation to the Cedar Rapids .NET User Group (CRineta.org) in 2006.
Sania: Syntactic and Semantic Analysis for Automated Testing against SQL Inje...Yuji Kosuga
With the recent rapid increase in interactive web applications that employ back-end database services, an SQL injection attack has become one of the most serious security threats. The SQL injection attack allows an attacker to access the underlying database, execute arbitrary commands at intent, and receive a dynamically generated output, such as HTML web pages. In this paper, we present our technique, Sania, for detecting SQL injection vulnerabilities in web applications during the development and debugging phases. Sania intercepts the SQL queries between a web application and a database, and automatically generates elaborate attacks according to the syntax and semantics of the potentially vulnerable spots in the SQL queries. In addition, Sania compares the parse trees of the intended SQL query and those resulting after an attack to assess the safety of these spots. We evaluated our technique using real-world web applications and found that our solution is efficient in comparison with a popular web application vulnerabilities scanner. We also found vulnerability in a product that was just about to be released.
Automated Detection of Session Fixation VulnerabilitiesYuji Kosuga
Session fixation is a technique for obtaining the visitor's session identifier (SID) by forcing the visitor to use the SID supplied by the attacker. The attacker who obtains the victim's SID can masquerade as the visitor. In this paper, we propose a technique to automatically detect session fixation vulnerabilities in web applications. Our technique uses attack simulator that executes a real session fixation attack and check whether it is successful or not. In the experiment, our system successfully detected vulnerabilities in our original test cases and in a real world web application.
International Journal of Engineering Research and Applications (IJERA) is an open access online peer reviewed international journal that publishes research and review articles in the fields of Computer Science, Neural Networks, Electrical Engineering, Software Engineering, Information Technology, Mechanical Engineering, Chemical Engineering, Plastic Engineering, Food Technology, Textile Engineering, Nano Technology & science, Power Electronics, Electronics & Communication Engineering, Computational mathematics, Image processing, Civil Engineering, Structural Engineering, Environmental Engineering, VLSI Testing & Low Power VLSI Design etc.
Ever faster agile development and a wide gap across development and security teams are 2 of the main reasons you want to entirely automate all aspects of API security: code scans, infra scans, security testing, automatic policies deployment and deployment of lightweight, secure enforcement points (PEPs). Let's shift left!
Presentation given at APIDays Paris in Jan 2018.
Table of Content
Web Application Firewall
possible security measures of WAF
Data Validation Strategies
Varieties Of Input
Reject Known Bad
Accept Known Good
Sanitization Safe Data Handling
Semantic Checks
Introduction SQL Injection
A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application
SQL Injection
Blind SQL Injection
Threat modeling is an approach for analyzing the security of an application.
It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application
Threat modeling is not an approach to reviewing code, but it does complement the security code review process.
The inclusion of threat modeling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning.
SQL injection is a type of security exploit in which the attacker adds Structured Query Language (SQL) code to a Web form input box to gain access to resources or make changes to data. An SQL query is a request for some action to be performed on a database. Typically, on a Web form for user authentication, when a user enters their name and password into the text boxes provided for them, those values are inserted into a SELECT query. If the values entered are found as expected, the user is allowed access; if they aren't found, access is denied. However, most Web forms have no mechanisms in place to block input other than names and passwords. Unless such precautions are taken, an attacker can use the input boxes to send their own request to the database, which could allow them to download the entire database or interact with it in other illicit ways.
Sergey Kochergan - OWASP Top 10 Web Application Vulnerabilities Braindev Kyiv
Sergey Kochergan is QA Engineer at Luxoft with extensive experience in software engineering and security field. As an independent consultant, he has provided strategic expertise to business clients with frameworks for SCADA security policy, organazied hackatons and ctf events. Sergey was involved into R&D projects of System Design for SDR communication hardware, network forensics with IDS.
In this lecture Sergey will tell the audience about Security in general, will make overview of nowadays Web Testing Environment and also will present his vision of Risk Rating Methodology and Vulnerability Patterns.
For our next events join us:
http://www.meetup.com/Kyiv-Dev-Meetup-SmartMonday/
https://www.facebook.com/braindevkyiv
Application Security Vulnerabilities: OWASP Top 10 -2007Vaibhav Gupta
General concepts of web application security vulnerabilities primarily based on OWASP Top 10 list-2007(I know its too old :-))
I, along with Sandeep and Vishal, presented on this at IIIT-Delhi college in April, 2014
Injecting Security into Web apps at Runtime WhitepaperAjin Abraham
This paper discusses the research outcomes on implementing a runtime application patching algorithm on an insecurely-coded application to protect it against code injection vulnerabilities and other logical issues related to web applications, and will introduce the next generation web application defending technology dubbed as Runtime Application Self-Protection (RASP) that defends against web attacks by working inside your web application. RASP relies on runtime patching to inject security into web apps implicitly without introducing additional code changes. The talk concludes with the challenges in this new technology and gives you an insight on future of runtime protection.
Web Security - OWASP - SQL injection & Cross Site Scripting XSSIvan Ortega
What is it?
How to prevent?
How to test my application web?
what say OWASP about it
All about SQL injection and Cross Site Scripting XSS
Tools to test our application web
Rules to prevent attacks from Hackers on our web
Ever faster agile development and a wide gap across development and security teams are 2 of the main reasons you want to entirely automate all aspects of API security: code scans, infra scans, security testing, automatic policies deployment and deployment of lightweight, secure enforcement points (PEPs). Let's shift left!
Presentation given at APIDays Paris in Jan 2018.
Table of Content
Web Application Firewall
possible security measures of WAF
Data Validation Strategies
Varieties Of Input
Reject Known Bad
Accept Known Good
Sanitization Safe Data Handling
Semantic Checks
Introduction SQL Injection
A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application
SQL Injection
Blind SQL Injection
Threat modeling is an approach for analyzing the security of an application.
It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application
Threat modeling is not an approach to reviewing code, but it does complement the security code review process.
The inclusion of threat modeling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning.
SQL injection is a type of security exploit in which the attacker adds Structured Query Language (SQL) code to a Web form input box to gain access to resources or make changes to data. An SQL query is a request for some action to be performed on a database. Typically, on a Web form for user authentication, when a user enters their name and password into the text boxes provided for them, those values are inserted into a SELECT query. If the values entered are found as expected, the user is allowed access; if they aren't found, access is denied. However, most Web forms have no mechanisms in place to block input other than names and passwords. Unless such precautions are taken, an attacker can use the input boxes to send their own request to the database, which could allow them to download the entire database or interact with it in other illicit ways.
Sergey Kochergan - OWASP Top 10 Web Application Vulnerabilities Braindev Kyiv
Sergey Kochergan is QA Engineer at Luxoft with extensive experience in software engineering and security field. As an independent consultant, he has provided strategic expertise to business clients with frameworks for SCADA security policy, organazied hackatons and ctf events. Sergey was involved into R&D projects of System Design for SDR communication hardware, network forensics with IDS.
In this lecture Sergey will tell the audience about Security in general, will make overview of nowadays Web Testing Environment and also will present his vision of Risk Rating Methodology and Vulnerability Patterns.
For our next events join us:
http://www.meetup.com/Kyiv-Dev-Meetup-SmartMonday/
https://www.facebook.com/braindevkyiv
Application Security Vulnerabilities: OWASP Top 10 -2007Vaibhav Gupta
General concepts of web application security vulnerabilities primarily based on OWASP Top 10 list-2007(I know its too old :-))
I, along with Sandeep and Vishal, presented on this at IIIT-Delhi college in April, 2014
Injecting Security into Web apps at Runtime WhitepaperAjin Abraham
This paper discusses the research outcomes on implementing a runtime application patching algorithm on an insecurely-coded application to protect it against code injection vulnerabilities and other logical issues related to web applications, and will introduce the next generation web application defending technology dubbed as Runtime Application Self-Protection (RASP) that defends against web attacks by working inside your web application. RASP relies on runtime patching to inject security into web apps implicitly without introducing additional code changes. The talk concludes with the challenges in this new technology and gives you an insight on future of runtime protection.
Web Security - OWASP - SQL injection & Cross Site Scripting XSSIvan Ortega
What is it?
How to prevent?
How to test my application web?
what say OWASP about it
All about SQL injection and Cross Site Scripting XSS
Tools to test our application web
Rules to prevent attacks from Hackers on our web
How to Make Your NodeJS Application Secure (24 Best Security Tips )Katy Slemon
For the start-ups that are already using Node.js in their web application, even you can implement these top 24 security tips to keep your Node.js app free from attacks.
"Welcome to the OWASP Top 10 2010! This significant update presents a more concise, risk focused list of the Top 10 Most Critical Web Application Security Risks. The OWASP Top 10 has always been about risk, but this update makes this much more clear than previous editions, and provides additional information on how to assess these risks for your applications.
For each top 10 item, this release discusses the general likelihood and consequence factors that are used to categorize the typical severity of the risk, and then presents guidance on how to verify whether you have this problem, how to avoid this problem, some example flaws in that area, and pointers to links with more information.
The primary aim of the OWASP Top 10 is to educate developers, designers, architects and organizations about the consequences of the most important web application security weaknesses. The Top 10 provides basic methods to protect against these high risk problem areas – a great start to your secure coding security program."
VSEC’s source code review services help uncover unexpected and hidden vulnerabilities and design flaws in source codes. We use a mix of scanning tools and manual review to detect insecure coding practices, injection flaws, cross site scripting flaws, backdoors, weak cryptography, insecure handling of external resources, etc.
Make sure you’re defending against the most common web security issues and attacks with this useful overview of software development best-practices. We'll go over the most common attacks against web applications and present real world advice for defending yourself against these types of attacks.
The developers of our Java web application development company are well-versed in the programming language. With years of experience and knowledge, they are aware of all the Java security issues and the fixes that fortify security. If you want to create an application that is safe and robust, contact us at any time.
OWASP Top 10 Vulnerabilities 2017- AppTranaIshan Mathur
Our latest OWASP Top Vulnerabilities Guide updated for new 2017 issues serves as a practical guide to understanding OWASP Top 10 vulnerabilities and preparing a response plan to counter these vulnerabilities.
This paper covers a new technique that can help IDS/IPS solution developers to provide more protection against web attacks. The approach is very generic and can be “adopted” by any IDS/IPS solution provider. Presently the approach is just an Idea and it requires more research and experiment to convert it into a working solution.
This approach helps in enhancing quality of “signature based IDS/IPS solution” and provides good coverage with respect to the evasion techniques.
The Web AppSec How-To: The Defender's ToolboxCheckmarx
Web application security has made headline news in the past few years. In this article, we review the various Web application security tools and highlight important decision factors to help you choose the application security technology best suited for your environment.
8 Patterns For Continuous Code Security by Veracode CTO Chris WysopalThreat Stack
Deploying insecure web applications into production can be risky -- resulting in potential loss of customer data, corporate intellectual property and/or brand value. Yet many organizations still deploy public-facing applications without assessing them for common and easily-exploitable vulnerabilities such as SQL Injection and Cross-Site Scripting (XSS).
This is because traditional approaches to application security are typically complex, manual and time-consuming – deterring agile teams from incorporating code analysis into their sprints.
But it doesn’t have to be that way. By incorporating key SecDevOps concepts into the Software Development Lifecycle (SDLC) – including centralized policies and tighter collaboration and visibility between security and DevOps teams – we can now embed continuous code-level security and assessment into our agile development processes. We’ve uncovered eight patterns that work together to transform cumbersome waterfall methodologies into efficient and secure agile development.
OWASP Top 10 List Overview for Web DevelopersBenjamin Floyd
The OWASP Top 10 List was recently updated for 2013, and many developers still do not know what it is or why they should care. It is a list of the top web security threats developers need to address to produce secure websites. Most developers aren't security experts, so the OWASP Top 10 Project has created resources designed for developers to quickly test their applications. Come hear about the list, why and how you can use it to make your job easier, and learn about resources you can use to quickly determine if your applications are addressing security threats properly.
My presentation about Web Apps security threats. Macedonian Code Camp conference 2013.
“Every program has at least two purposes: the one for which it was written, and another for which it wasn't.”
-Alan J. Perlis
1. Working
Papers
in
Application
Security
Protecting Your
Web Apps
Two Big Mistakes and 12 Practical Tips
to Avoid Them
Volume 1.1 Written by Frank Kim and Ed Skoudis
2. I ncreasingly, computer attackers are exploiting flaws in Web applications, exposing
enterprises to significant threats, including Personally Identifiable Information breaches
and uploads of malware onto vulnerable corporate Websites for distribution to customer
Working Papers in browsers. Many of these Web application vulnerabilities are a direct result of improper
input validation and output filtering, which leads to numerous kinds of attacks, including
Application Security cross-site scripting (XSS), SQL injection, command injection, buffer overflows and many
others. This article describes some of the best defenses against such attacks, which every
Web application developer should master.
Whenever an application needs to gather information from a user or a browser, that
information must be validated carefully to remove potential attack strings. Likewise, data
sent back from the Web server to a browser should be filtered to make sure that exploits
that an attacker has managed to sneak onto a Web server aren’t served back to unwitting
consumers who visit the site.
Protecting As an example, consider a Web site that needs to gather from a user a specific name and
age for processing. One alpha field and one numeric field would likely suffice to gather
Your this information. Without proper validation, however, attackers might be able to use
other characters, including semicolons, greater-than or less-than symbols, and quotation
Web Apps marks to exploit the application. If a software developer does not properly screen all
forms of user input to prevent certain characters from being entered, the software may
be exploitable in numerous different ways. Input validation acts as a shield by deflecting
Two Big Mistakes potentially malicious characters. Likewise, output filtering prevents the Website from
shooting back an exploit to browsers. Protection in both directions is needed, and Web
and 12 Practical Tips application developers are a crucial line of such defense.
to Avoid Them Unfortunately, some software developers either leave out input-validation and output-
filtering code altogether, or they implement such code poorly so that it does not filter out
Written by a truly comprehensive set of potential attack characters. Also, there are dozens of ways to
Frank Kim and alter or encode data to dodge validation filters: UTF-8, Hex, Unicode, mixed case and many
Ed Skoudis more. Noted Web app security guru RSnake has written a great Web page that shows
some different encoding tricks designed to slip cross-site scripting attacks past weak
input-validation code http://ha.ckers.org/xss.html.
With that overview in mind, let’s look carefully at the methods that developers should
employ to prevent input-validation attacks and implement better output filtering. For
software developers who want to make sure that their input-validation and output filtering
code is up to snuff, use the following as a checklist:
This article is the first in a series
1. Use well known and carefully vetted validation code
dedicated to application security
and secure coding practices.
In coming months, the SANS Rather than rolling your own code for user input validation, use APIs that have been
Institute will release additional carefully developed and rigorously tested by others. Some software development firms
articles like this that cover other and large enterprises doing in-house development have defined reusable input validation
aspects of application security and code for all software they create. Find out if your organization has such code, learn how
secure coding. However, please it works, and then use it. If you don’t have such code in-house, you can utilize code from
don’t wait until the end of the series a variety of free sources. For example, Apache Struts is a very popular MVC framework
to start following these tips. for Web applications built in Java. If you are using Struts, you can leverage its built-
Make a commitment today to in validation framework to apply input validation rules to your data. Additionally, the
ensuring that your applications OWASP Enterprise Security API (ESAPI) project provides interfaces and implementations
and code are more secure. of important security functions including input validation and output encoding. ESAPI
is currently implemented in Java, with .NET and PHP versions in the works. The code
www.sans.org/info/39149 examples in this article will utilize the Java version of ESAPI.
3. 2. Specify variable types
Limit the kind of data that can be entered into some fields. For example, if you only need
to accept an integer in a field, ensure that your code rejects any other characters that may
Working Papers in be entered. One way to accomplish this is by using the Validator class from ESAPI. This
class has an isValidInteger method that can be used as follows in Java code:
Application Security
Validator validator = ESAPI.validator();
boolean isValidInteger =
validator.isValidInteger(“Test_Num”, “42”, 0, 999, false);
As described in the ESAPI Javadoc, the isValidInteger method takes five parameters:
• context - This is a descriptive name for the parameter we are validating. In this case,
we’ve used the string “Test_Num” .
• input - The actual data we want to validate. In this case it is the string “42”
.
• minValue - The lowest legal value.
Protecting
• maxValue - The highest legal value.
• allowNull - A boolean indicating whether or not the field can be null.
Your Our code first calls ESAPI.validator(). The ESAPI class is a locator class that can
be used to retrieve default implementations of various ESAPI classes. In this case we
Web Apps use the validator method to retrieve ESAPI’s default validator and then call the
isValidInteger method on that Validator instance. If the input is a valid integer per
our specifications, then the method returns true. Otherwise, our code needs to reject that
Two Big Mistakes input. Simple as that!
and 12 Practical Tips 3. Don’t define all possible bad characters;
instead accept only the good ones
to Avoid Them
Trying to create a comprehensive list of all bad characters for all the different kinds of
Written by
attacks is next to impossible. Thus, when creating validation code, define which characters
Frank Kim and
are acceptable using a whitelist, such as A-Z, a-z, and 0-9, and reject everything else. Such
Ed Skoudis a “deny-all-except-for-certain-allowable-characters” approach is a far stronger way to write
validation code. We’ll cover some example code that implements this recommendation
below, bundled with the next suggestion.
4. Limit the size of input
If you ask for someone’s age, keeping it to a three-digit field will cover every reasonable
case, even the centenarians in your user population. If you ask for someone’s name, a
hundred or so characters are reasonable. That way, even if you aren’t properly filtering for
characters, you are still limiting the real estate that the attacker has to pull off an attack.
To both validate input using a whitelist approach and limit the size of our input, we
can once again use the Validator class in Java. This time, however, we use the
isValidInput method as follows:
Validator validator = ESAPI.validator();
boolean isValidFirstName =
validator.isValidInput(“Test_AccountName”, “Checking1”,
www.sans.org/info/39149 “AccountName”, 100, false);
4. The isValidInput method takes five parameters:
• context - As before, this is a descriptive name for the parameter we are validating. In
this case we use the string “Test_AccountName” .
Working Papers in • input - The actual data we want to validate. Here, we are analyzing the string
“Checking1”.
Application Security
• type - The name of a regular expression that maps to the actual regular expression in
the ESAPI.properties configuration file.
• maxLength - The maximum length allowed for the input data.
• allowNull - A boolean indicating whether or not the field can be null.
The “AccountName” regular expression we defined in the ESAPI configuration file is
^[a-zA-Z0-9]*$
This regex essentially says that the input is allowed to only contain lower and uppercase
letters and numbers from zero to nine. Additionally, in the isValidInput call, we
specified that the maxLength for the input cannot exceed 100 characters. These input
Protecting
validation rules will block many types of attack.
5. Canonicalize before filtering
Your If user input is encoded in a fashion that your filters aren’t designed to handle, your
Web Apps application very well might get hacked. Thus, whenever you receive user input, convert
it to a standard encoding scheme, such as plain ASCII, before applying your filters. This
process is known as canonicalization, and it converts a character stream of different
Two Big Mistakes encoding patterns to a simpler, consistent format that your filters can handle properly.
and 12 Practical Tips Fortunately, ESAPI performs canonicalization for us before doing any input validation.
For example, when we called the isValidInput method above, ESAPI automatically
to Avoid Them canonicalized the input data by using the Encoder class under the covers. We can also
explicitly invoke this functionality by calling the canonicalize method as follows (note
Written by that Exception handling has been removed for readability):
Frank Kim and String encoded = “%3Cscript>alert%28%27xss'%29%3C%2Fscript%3E”;
Ed Skoudis Encoder encoder = ESAPI.encoder();
String decodedString = encoder.canonicalize(encoded);
When this code is executed, the decodedString variable will contain the value
<script>alert(‘xss’)</script>
There are many ways to represent different characters depending on the encoding
scheme in use. In the example above both > and %3E are encoded representations
of the greater-than character (>). Some simple validation filters may look for the less-
than and greater-than characters in an attempt to prevent XSS attacks. However, filters
may be bypassed if data is not properly canonicalized before input validation checks are
performed.
6. Filter all input
Filter every form of input to your application, including data that comes in via the network,
the GUI, hidden form elements, cookies, files read from the file system and so on. Don’t
assume that one of your fields or input vectors isn’t important. Attackers will hunt for
www.sans.org/info/39149 weaknesses and exploit them, so cover all of your bases.
5. 7. Filter on the server side
In many applications, attackers might be able to control clients, such as browsers or thick-
client GUIs, tweaking their functionality to bypass filtering done at the client. Alternatively,
Working Papers in particularly creative attackers may devise their own custom clients designed just to attack
your Web application code. JavaScript, pull-down menus, and other client-side filters can
Application Security improve usability, but they are trivial for attackers to bypass and therefore don’t provide
security. Thus, you can’t rely on security checks at the client side, because it is territory
outside of your control. Filter on the server side to protect all back-end functionality.
8. Don’t worry about multiple layers of validation
Sometimes, what appears to be a single application will include multiple subsystems.
For example, a Web application may utilize a Web service under the covers. The Web
application performs data validation before calling the Web service and the Web service
in turn performs the same validation checks before it begins processing the data. This
design could result in a single set of input getting filtered multiple times as it snakes its
way through the application. While that might be a performance concern, it’s actually a
Protecting good thing from a security perspective, especially considering that other clients could call
the Web service directly in the future. Multiple layers of filtering help provide defense in
Your
depth, making the whole system more secure.
9. Utilize output encoding
Web Apps Output encoding takes place when data is displayed back to the user or utilized by another
component of the application. By properly escaping data before it is used, many types of
Two Big Mistakes attacks can be prevented. For example, certain characters, like the less-than and greater-
than symbols, are commonly used in XSS attacks. By converting these characters to their
and 12 Practical Tips HTML entity equivalents (i.e., “<” becomes “<” and “>” becomes “>”), many XSS attacks
to Avoid Them can be prevented. The Encoder class contains numerous methods that can be used to
encode data for a number of different situations. Specifically, the encodeForHTML method
can be used to prevent HTML-based XSS as follows:
Written by
Frank Kim and Encoder encoder = ESAPI.encoder();
Ed Skoudis String encodedString = encoder.encodeForHTML(“<script>alert
(‘xss’)</script>”);
When this code is executed, the encodedString variable will contain the following value,
which is far less likely to be executed as a script in a browser during an XSS attack attempt:
<script>alert('xss')</script>
The encodeForHTML method actually takes a whitelist approach to encoding. It treats
a limited set of characters (letters, numbers, commas, periods, dashes, underscores, and
spaces) as safe and HTML encodes everything else. When the browser displays HTML
encoded data, it renders it for display only and not execution, thereby preventing XSS
attacks.
www.sans.org/info/39149
6. 10. Choose the appropriate output encoding
HTML output encoding is only one example of how data may need to be encoded.
Depending on where your data is used, other encoding schemes may need to be applied.
Working Papers in For example, XSS can also occur if malicious data is utilized in JavaScript. Moreover, data
used as part of XML elements, XPATH queries, or operating system commands will also
Application Security benefit from proper output encoding. Ensure that you perform the appropriate encoding
depending on where your data will be utilized. Fortunately, the Encoder class contains
encodeForJavaScript, encodeForXML, encodeForXPath, and encodeForOS methods
that provide this functionality for you.
11. Conduct a secure code review
To help ensure that the source code for your application does not contain security
vulnerabilities, conduct a professional code review to see if any security issues can be
discovered and remediated.
12. Perform a penetration test
Protecting To check for any remaining vulnerabilities, subject your application to a controlled
Your penetration test to see if flaws can be identified.
Web Apps So there you have it. These 12 recommendations can go a long way toward making your
application code more secure. They won’t make your code bulletproof, but they can thwart
a large number of common and very damaging attacks.
Two Big Mistakes
and 12 Practical Tips
to Avoid Them
Written by
Frank Kim and
Ed Skoudis
About the authors
Ed Skoudis is a SANS Fellow and co-founder of InGuardians, an infosec consulting and
cutting-edge research company (www.inguardians.com). Author of the acclaimed SANS
SEC504 and SEC560 courses, Ed’s expertise includes in-depth penetration testing and
incident response.
Frank Kim is a SANS author and instructor and founder of Think Security (www.thinksec.
com). He has been developing, designing, and securing Web applications for over ten
years. He currently focuses on integrating security into the SDLC by doing architecture
www.sans.org/info/39149 reviews, security assessments, code reviews, penetration testing, and training.