The document discusses the history and development of the Document Object Model (DOM) from its early implementations in 1995 to modern standards. It outlines key milestones like DOM Level 1 in 1998, the rise of JavaScript frameworks like Prototype, jQuery and MooTools in 2005-2006, and ongoing work by the W3C and WHATWG. The talk will explore security issues that can arise from the DOM's ability to convert strings to executable code and demonstrate an attack technique called DOM clobbering.
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...Mario Heiderich
ECMAScript 6, in short ES6, has been boiling in a copper pot for many years by now and step-by-step, browser vendors come forward to taste the first sips of this mystery soup. So, ES6 is no longer a theoretic language but already crawled across the doorstep and now lurks under your bed, ready for the nasty, waiting for the right moment to bite.
Now, what is this whole ES6 thing? How did it develop and who made it? And why is it now implemented in your favorite browser? And what does it mean for web-security and beyond?
This talk will answer these questions and showcase the new language from an attacker's perspective. You will see the new code constructs possible to be executed with ES6, new attack vectors and learn what you can do to tame that beast. Kafkaesque terminology such as expression interpolation, proper tail calls, computed properties, spread parameters, modules and tagged template strings will no longer be surprising you after attending this talk.
This talk introduces and discusses a novel, mostly unpublished technique to successfully attack websites that are applied with state-of-the-art XSS protection. This attack labeled Mutation-XSS (mXSS) is capable of bypassing high-end filter systems by utilizing the browser and its unknown capabilities - every single f***** one of them. We analyzed the type and number of high-profile websites and applications that are affected by this kind of attack. Several live demos during the presentation will share these impressions and help understanding, what mXSS is, why mXSS is possible and why it is of importance for defenders as well as professional attackers to understand and examine mXSS even further. The talk wraps up several years of research on this field, shows the abhorrent findings, discusses the consequences and delivers a step-by-step guide on how to protect against this kind of mayhem - with a strong focus on feasibility and scalability.
OWASP SF - Reviewing Modern JavaScript ApplicationsLewis Ardern
When dealing with modern JavaScript applications, many penetration testers approach from an ‘out-side-in’ perspective, this is approach often misses security issues in plain sight. This talk will attempt to demystify common JavaScript issues which should be better understood/identified during security reviews. We will discuss reviewing applications in code-centric manner by using freely available tools to help start identifying security issues through processes such as linting and dependency auditing.
XSS is much more than just <script>alert(1)</script>. Thousands of unique vectors can be built and more complex payloads to evade filters and WAFs. In these slides, cool techniques to bypass them are described, from HTML to javascript. See also http://brutelogic.com.br/blog
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.
ECMAScript 6 from an Attacker's Perspective - Breaking Frameworks, Sandboxes,...Mario Heiderich
ECMAScript 6, in short ES6, has been boiling in a copper pot for many years by now and step-by-step, browser vendors come forward to taste the first sips of this mystery soup. So, ES6 is no longer a theoretic language but already crawled across the doorstep and now lurks under your bed, ready for the nasty, waiting for the right moment to bite.
Now, what is this whole ES6 thing? How did it develop and who made it? And why is it now implemented in your favorite browser? And what does it mean for web-security and beyond?
This talk will answer these questions and showcase the new language from an attacker's perspective. You will see the new code constructs possible to be executed with ES6, new attack vectors and learn what you can do to tame that beast. Kafkaesque terminology such as expression interpolation, proper tail calls, computed properties, spread parameters, modules and tagged template strings will no longer be surprising you after attending this talk.
This talk introduces and discusses a novel, mostly unpublished technique to successfully attack websites that are applied with state-of-the-art XSS protection. This attack labeled Mutation-XSS (mXSS) is capable of bypassing high-end filter systems by utilizing the browser and its unknown capabilities - every single f***** one of them. We analyzed the type and number of high-profile websites and applications that are affected by this kind of attack. Several live demos during the presentation will share these impressions and help understanding, what mXSS is, why mXSS is possible and why it is of importance for defenders as well as professional attackers to understand and examine mXSS even further. The talk wraps up several years of research on this field, shows the abhorrent findings, discusses the consequences and delivers a step-by-step guide on how to protect against this kind of mayhem - with a strong focus on feasibility and scalability.
OWASP SF - Reviewing Modern JavaScript ApplicationsLewis Ardern
When dealing with modern JavaScript applications, many penetration testers approach from an ‘out-side-in’ perspective, this is approach often misses security issues in plain sight. This talk will attempt to demystify common JavaScript issues which should be better understood/identified during security reviews. We will discuss reviewing applications in code-centric manner by using freely available tools to help start identifying security issues through processes such as linting and dependency auditing.
XSS is much more than just <script>alert(1)</script>. Thousands of unique vectors can be built and more complex payloads to evade filters and WAFs. In these slides, cool techniques to bypass them are described, from HTML to javascript. See also http://brutelogic.com.br/blog
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.
OWASP SD: Deserialize My Shorts: Or How I Learned To Start Worrying and Hate ...Christopher Frohoff
Object deserialization is an established but poorly understood attack vector in applications that is disturbingly prevalent across many languages, platforms, formats, and libraries.
In January 2015 at AppSec California, Chris Frohoff and Gabe Lawrence gave a talk on this topic, covering deserialization vulnerabilities across platforms, the many forms they take, and places they can be found. It covered, among other things, somewhat novel techniques using classes in commonly used libraries for attacking Java serialization that were subsequently released in the form of the ysoserial tool. Few people noticed until late 2015, when other researchers used these techniques/tools to exploit well known products such as Bamboo, WebLogic, WebSphere, ApacheMQ, and Jenkins, and then services such as PayPal. Since then, the topic has gotten some long-overdue attention and great work is being done by many to improve our understanding and developer awareness on the subject.
This talk will review the details of Java deserialization exploit techniques and mitigations, as well as report on some of the recent (and future) activity in this area.
http://www.meetup.com/Open-Web-Application-Security-Project-San-Diego-OWASP-SD/events/226242635/
Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-...Mario Heiderich
The clipboard is one of the most commonly used tools across operating systems, window managers and devices. Pressing Ctrl-C and Ctrl-V has become so fundamentally important to productivity and usability that we cannot get rid of it anymore. We happily and often thoughtlessly copy things from one source and paste them into another. URLs into address-bars, lengthy commands into console windows, text segments into web editors and mail interfaces. And we never worry about security when doing so. Because what could possibly go wrong, right?
But have we ever asked ourselves what the clipboard content actually consists of? Do we really know what it contains? And are we aware of the consequences a thoughtless copy&paste interaction can have? Who else can control the contents of the clipboard? Is it really just us doing Ctrl-C or is there other forces in the realm who are able to infect what we believe to be clean, who can desecrate what we trust so blindly that we never question or observe it?
This talk is about the clipboard and the technical details behind it. How it works, what it really contains – and who can influence its complex range of contents. We will learn about a new breed of targeted attacks, including cross-application XSS from PDF, ODT, DOC and XPS that allow to steal website accounts faster than you can click, turn your excel sheet into a monster and learn about ways to smuggle creepy payload that is hidden from sight until it executes. Oh, and we’ll also see what can be done about that and what defensive measures we achieved to create so far.
This talk shares the various techniques I found whilst building the XSS cheat sheet. It contains auto executing vectors, AngularJS CSP bypasses and dangling markup attacks.
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.
넥슨코리아 사내 발표자료로 왓 스튜디오에서 파이썬으로 《야생의 땅: 듀랑고》 서버를 비롯한 여러가지 도구를 만든 경험을 공유합니다.
- 게임서버와 각종 툴, 테스트/빌드/배포 시스템을 만들 때 사용한 재료
- 파이썬 코드 품질 개선, 디버깅, 프로파일링, 최적화
- 파이썬 오픈소스 생태계와 왓 스튜디오가 하는 오픈소스 활동
OWASP AppSecEU 2018 – Attacking "Modern" Web TechnologiesFrans Rosén
In this talk, top ranked white-hat hacker Frans Rosén (@fransrosen) will focus on methodologies and results of attacking modern web technologies. He will do a deep-dive in postMessage, how vulnerable configurations in both AWS and Google Cloud allow attackers to take full control of your assets.
Listen to 60 minutes of new hacks, bug bounty stories and learnings that will make you realize that the protocols and policies you believed to be secure are most likely not.
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWT is widely used technology specially for API's authentication. This PPT describes about security concerns with JWT..
JavascriptMVC: Another choice of web frameworkAlive Kuo
JavascriptMVC is another client side web MVC framework based on jQuery. It has totally solution to build a web application. This slide will introduce basic features of JavascriptMVC3.2
OWASP SD: Deserialize My Shorts: Or How I Learned To Start Worrying and Hate ...Christopher Frohoff
Object deserialization is an established but poorly understood attack vector in applications that is disturbingly prevalent across many languages, platforms, formats, and libraries.
In January 2015 at AppSec California, Chris Frohoff and Gabe Lawrence gave a talk on this topic, covering deserialization vulnerabilities across platforms, the many forms they take, and places they can be found. It covered, among other things, somewhat novel techniques using classes in commonly used libraries for attacking Java serialization that were subsequently released in the form of the ysoserial tool. Few people noticed until late 2015, when other researchers used these techniques/tools to exploit well known products such as Bamboo, WebLogic, WebSphere, ApacheMQ, and Jenkins, and then services such as PayPal. Since then, the topic has gotten some long-overdue attention and great work is being done by many to improve our understanding and developer awareness on the subject.
This talk will review the details of Java deserialization exploit techniques and mitigations, as well as report on some of the recent (and future) activity in this area.
http://www.meetup.com/Open-Web-Application-Security-Project-San-Diego-OWASP-SD/events/226242635/
Copy & Pest - A case-study on the clipboard, blind trust and invisible cross-...Mario Heiderich
The clipboard is one of the most commonly used tools across operating systems, window managers and devices. Pressing Ctrl-C and Ctrl-V has become so fundamentally important to productivity and usability that we cannot get rid of it anymore. We happily and often thoughtlessly copy things from one source and paste them into another. URLs into address-bars, lengthy commands into console windows, text segments into web editors and mail interfaces. And we never worry about security when doing so. Because what could possibly go wrong, right?
But have we ever asked ourselves what the clipboard content actually consists of? Do we really know what it contains? And are we aware of the consequences a thoughtless copy&paste interaction can have? Who else can control the contents of the clipboard? Is it really just us doing Ctrl-C or is there other forces in the realm who are able to infect what we believe to be clean, who can desecrate what we trust so blindly that we never question or observe it?
This talk is about the clipboard and the technical details behind it. How it works, what it really contains – and who can influence its complex range of contents. We will learn about a new breed of targeted attacks, including cross-application XSS from PDF, ODT, DOC and XPS that allow to steal website accounts faster than you can click, turn your excel sheet into a monster and learn about ways to smuggle creepy payload that is hidden from sight until it executes. Oh, and we’ll also see what can be done about that and what defensive measures we achieved to create so far.
This talk shares the various techniques I found whilst building the XSS cheat sheet. It contains auto executing vectors, AngularJS CSP bypasses and dangling markup attacks.
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.
넥슨코리아 사내 발표자료로 왓 스튜디오에서 파이썬으로 《야생의 땅: 듀랑고》 서버를 비롯한 여러가지 도구를 만든 경험을 공유합니다.
- 게임서버와 각종 툴, 테스트/빌드/배포 시스템을 만들 때 사용한 재료
- 파이썬 코드 품질 개선, 디버깅, 프로파일링, 최적화
- 파이썬 오픈소스 생태계와 왓 스튜디오가 하는 오픈소스 활동
OWASP AppSecEU 2018 – Attacking "Modern" Web TechnologiesFrans Rosén
In this talk, top ranked white-hat hacker Frans Rosén (@fransrosen) will focus on methodologies and results of attacking modern web technologies. He will do a deep-dive in postMessage, how vulnerable configurations in both AWS and Google Cloud allow attackers to take full control of your assets.
Listen to 60 minutes of new hacks, bug bounty stories and learnings that will make you realize that the protocols and policies you believed to be secure are most likely not.
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWT is widely used technology specially for API's authentication. This PPT describes about security concerns with JWT..
JavascriptMVC: Another choice of web frameworkAlive Kuo
JavascriptMVC is another client side web MVC framework based on jQuery. It has totally solution to build a web application. This slide will introduce basic features of JavascriptMVC3.2
The Chromium project's Way to Wayland (FOSDEM 2018)Igalia
By Maksim Sisov.
Wayland is the most advanced X11-alternative display protocol, shipping today in a variety of desktop and embedded environments. Although the Chromium browser on Linux still defaults to use the X11 window system, there have been efforts to port it to different environments.
This effort happens in various fronts, including the development and stabilization of Ozone, an abstraction layer for graphics and input events, and the transitioning of some ChromeOS-oriented solutions to Linux, for example Chromium's new "UI service".
Igalia has been actively contributing to this multi organizational collaboration, aiming at getting a full fledged Chromium browser running natively on Wayland. The work happens on Chromium's upstream repository so that the greater Chromium community can benefit from it.
This presentation intends to show the Chromium project's way to Wayland.
Wayland is the most advanced X11-alternative display protocol, shipping today in a variety of desktop and embedded environments. Although the Chromium browser on Linux still defaults to use the X11 window system, there have been efforts to port it to different environments.
This effort happens in various fronts, including the development and stabilization of Ozone, an abstraction layer for graphics and input events, and the transitioning of some ChromeOS-oriented solutions to Linux, for example Chromium's new "UI service".
Igalia has been actively contributing to this multi organizational collaboration, aiming at getting a full fledged Chromium browser running natively on Wayland. The work happens on Chromium's upstream repository so that the greater Chromium community can benefit from it.
This presentation intends to show the Chromium project's way to Wayland.
(c) FOSDEM 2018
Brussels, 3 & 4 February 2018
https://fosdem.org/2018/schedule/event/chromium_to_wayland/
The intention of this presentation is to give an answer to WHY questions. I think this kind of content should be more present on the web. Example framework is Angular, but most of the presentation content is framework agnostic.
W prezentacji znajdziesz omówienie:
-organizację kodu i pracy w trochę większych projektach
-wykorzystanie narzędzi takich jak npm, gulp, sass, bower do automatyzacji zadań
-efektywną pracę w zespole z wykorzystaniem gita
-zasady tworzenia zwartego, łatwego w utrzymaniu kodu w oparciu o podejście SMACSS i BEM
-wzorce i podejście do tworzenia modularnego javascriptu
-przydatne narzędzia i biblioteki wraz z ich praktycznym zastosowaniem
-testowanie stron i aplikacji
-przyjrzymy się też nowej wersji Javascript: ES6/ES2015
jQuery is a fast, small, and feature-rich JavaScript library. It makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler with an easy-to-use API that works across a multitude of browsers. With a combination of versatility and extensibility, jQuery has changed the way that millions of people write JavaScript.
Platform - Depends on the size of the project and the type of its development, developers, and kind of platform.
Both the platforms Golang and Node.js were developed for different use & distinct purposes.
visit: https://www.forcebolt.com/
You Can Work on the Web Patform! (GOSIM 2023)Igalia
Have you ever wanted to work on a web browser? Servo is an experimental web
engine written in Rust. Its small code base and friendly community mean that it
is an ideal project for those looking to dip their toes into the world of web
browser engineering.
In this, Martin Robinson covers the basics of building and running
Servo on your own computer. In addition, we'll take a tour of Servo's main
subsystems and see what kind of work goes into building them. Additionally,
we'll cover a variety of types of contributions to Servo, adapted to different
kinds of experience and specialization. By the end you should have the tools
you need to explore contributing yourself.
(c) GOSIM Workshop 2023
Sept 23-24
Grand Hyatt, Pudong, Shanghai
https://workshop2023.gosim.org/
https://www.bilibili.com/video/BV1Hw411r7Q6/
By Antonio Gomes and Maksim Sisov.
Slides at https://docs.google.com/presentation/d/1CKhvcWpVcp8E_76zUnL6r4cmmMnL1onU1BsCxtx5Eak/edit#slide=id.p3
(c) BlinkOn 9
19 & 20 April, 2018
https://groups.google.com/a/chromium.org/forum/#!topic/embedder-dev/9SNHmSHWT6A
BYOD Revisited: Build Your Own Device (Embedded Linux Conference 2014)Ron Munitz
My session at the Embedded Linux Conference, April 2014, San Jose, CA
Think about the software development routines in the last couple of years. Now think of how they used to be before the "explosion" of cloud services provided by Amazon, Google, Rackspace, Microsoft and the likes.
Even when putting aside distinguished niches such as Safety Critical platforms, and ignoring for the moment the buzz for project management "Agile" methodologies, you will probably notice that the Software Building Practices have completely changed.
You will notice That developing a Software product has become more of an integration effort due to the "explosion" of open source repositories for "high level" components, and that the proficient software developer has become a master of Lego craft.
Now take a look at what Embedded Systems were back at the time, and what it is becoming these days. Not only can one choose their set of components, in ever decreasing prices, sell hardware on kickstarter before even starting a prototype, but one can also replace old times designated HW/SW assembly and libraries, and choose from a variety of Powerful General Purpose Operating Systems that can run servers, desktops, phones, tablets, fitness bracelets, and their next product.
Development has definitely evolved. From mainframes to AWS.
From the V2 analog controller to processing monsters running Linux, Android, Tizen, Windows, FireFoxOS, or your next hand made operating system.
In this session, I am going to present key milestones in the evolution of the Internet of Things, focusing on the present and immediate future techniques for rapidly prototyping and building product stacks, and discuss the many similarities of building a modern Software stack, and a modern Hardware stack.
For Training/Consulting requests: info@thepscg.com
AD109 Navigating the Jungle of Modern Web DevelopmentShean McManus
In the beginning, the web was built largely on static HTML pages. While HTML is still the foundation for the modern web page, the explosion of JavaScript libraries, CSS frameworks, development tools, platforms and cloud offerings have made the understanding the universe of modern web development much more challenging. What is Angular? The MEAN stack? What is the difference between HTML and HTML5 or CSS and CSS3? To break it all down I will attempt to provide a clear overview of today's web including a taxonomy of common languages, tools, platforms and libraries. Learn how IBM xPages and IBM Blue Mix fit into this world and how all the terms you hear every day fit into the larger picture of modern web development.
Similar to In the DOM, no one will hear you scream (20)
Dev and Blind - Attacking the weakest Link in IT SecurityMario Heiderich
The developer is an easy and valuable target for malicious minds. The reasons for that are numerous and hard to come by. This talk delivers examples, proof, discussion and awkward moments in a pretty special way.
Everybody hates developers – especially web developers. And why not? The cracks and crevices of their APIs and implementations are the reason that vulnerabilities in web applications are still a widespread issue – and will continue to be in the foreseeable future.
Bashing and blaming them for their wrongdoings is fun – boy, they are stupid in their mistakes! But has anyone ever dared to have an open on stage battle with an actual developer?
And who of the developers dares to face their collective nemesis – the attacker? Can there be life where matter and anti-matter collide? We will know about this soon – because this is what this talk is going to be about. Developer versus attacker – vulnerability versus defense. Be prepared for swearing, violence and people leaving the stage prematurely in tears.
Bridging the Digital Gap Brad Spiegel Macon, GA Initiative.pptxBrad Spiegel Macon GA
Brad Spiegel Macon GA’s journey exemplifies the profound impact that one individual can have on their community. Through his unwavering dedication to digital inclusion, he’s not only bridging the gap in Macon but also setting an example for others to follow.
Multi-cluster Kubernetes Networking- Patterns, Projects and GuidelinesSanjeev Rampal
Talk presented at Kubernetes Community Day, New York, May 2024.
Technical summary of Multi-Cluster Kubernetes Networking architectures with focus on 4 key topics.
1) Key patterns for Multi-cluster architectures
2) Architectural comparison of several OSS/ CNCF projects to address these patterns
3) Evolution trends for the APIs of these projects
4) Some design recommendations & guidelines for adopting/ deploying these solutions.
This 7-second Brain Wave Ritual Attracts Money To You.!nirahealhty
Discover the power of a simple 7-second brain wave ritual that can attract wealth and abundance into your life. By tapping into specific brain frequencies, this technique helps you manifest financial success effortlessly. Ready to transform your financial future? Try this powerful ritual and start attracting money today!
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
# Internet Security: Safeguarding Your Digital World
In the contemporary digital age, the internet is a cornerstone of our daily lives. It connects us to vast amounts of information, provides platforms for communication, enables commerce, and offers endless entertainment. However, with these conveniences come significant security challenges. Internet security is essential to protect our digital identities, sensitive data, and overall online experience. This comprehensive guide explores the multifaceted world of internet security, providing insights into its importance, common threats, and effective strategies to safeguard your digital world.
## Understanding Internet Security
Internet security encompasses the measures and protocols used to protect information, devices, and networks from unauthorized access, attacks, and damage. It involves a wide range of practices designed to safeguard data confidentiality, integrity, and availability. Effective internet security is crucial for individuals, businesses, and governments alike, as cyber threats continue to evolve in complexity and scale.
### Key Components of Internet Security
1. **Confidentiality**: Ensuring that information is accessible only to those authorized to access it.
2. **Integrity**: Protecting information from being altered or tampered with by unauthorized parties.
3. **Availability**: Ensuring that authorized users have reliable access to information and resources when needed.
## Common Internet Security Threats
Cyber threats are numerous and constantly evolving. Understanding these threats is the first step in protecting against them. Some of the most common internet security threats include:
### Malware
Malware, or malicious software, is designed to harm, exploit, or otherwise compromise a device, network, or service. Common types of malware include:
- **Viruses**: Programs that attach themselves to legitimate software and replicate, spreading to other programs and files.
- **Worms**: Standalone malware that replicates itself to spread to other computers.
- **Trojan Horses**: Malicious software disguised as legitimate software.
- **Ransomware**: Malware that encrypts a user's files and demands a ransom for the decryption key.
- **Spyware**: Software that secretly monitors and collects user information.
### Phishing
Phishing is a social engineering attack that aims to steal sensitive information such as usernames, passwords, and credit card details. Attackers often masquerade as trusted entities in email or other communication channels, tricking victims into providing their information.
### Man-in-the-Middle (MitM) Attacks
MitM attacks occur when an attacker intercepts and potentially alters communication between two parties without their knowledge. This can lead to the unauthorized acquisition of sensitive information.
### Denial-of-Service (DoS) and Distributed Denial-of-Service (DDoS) Attacks
APNIC Foundation, presented by Ellisha Heppner at the PNG DNS Forum 2024APNIC
Ellisha Heppner, Grant Management Lead, presented an update on APNIC Foundation to the PNG DNS Forum held from 6 to 10 May, 2024 in Port Moresby, Papua New Guinea.
APNIC Foundation, presented by Ellisha Heppner at the PNG DNS Forum 2024
In the DOM, no one will hear you scream
1. In the DOM,
no one will hear you scream
A journey into the moldy layer
between HTML and JavaScript
A talk by Mario Heiderich
mario@cure53.de || @0x6D6172696F
2. Meta-Expert, Philanthropist, Visionary
& Thought-Leader
● Dr.-Ing. Mario Heiderich
● Researcher and Post-Doc, Ruhr-Uni Bochum
– PhD Thesis about Client Side Security and Defense
● Founder of Cure53
– Pentest- & Security-Firm located in Berlin
– Consulting, Workshops, Trainings
– „Simply the Best Company in the World“
● Published Author and Speaker
– Specialized on HTML5, DOM and SVG Security
– JavaScript, XSS and Client Side Attacks
● HTML5 Security Cheatsheet
● And DOMPurify!
– @0x6D6172696F
– mario@cure53.de
3. Today's Menu
● The DOM (Document Object Model)
● Especially its weirder areas
● Origin and Goals
● History and first implementations
● Traps and Pitfalls
● Security Issues
● Countermeasures against those
● An Outlook
● No JavaScript-”Weirdness”
● No undefined==null and so on
● We'll stick with the DOM itself - the “Layer Between™”
● Focus on security for modern web apps
5. Ancient History
● The DOM as we know it today has made a very long way
● Baby steps were made as early as back in 1995
● „Legacy-DOM“ or DOM Level 0
● Implementations in Netscape 2.0 and MSIE 3.0
● No actual standard. And why would there be any.
● Partial documentation
● No common denominator among browsers
● JavaScript versus JScript
● Poor on features, no actual feature-parity to HTML
● Goals of that early DOM?
● Interactivity and easy element-access
● document.forms[0].elements[0]
● document.bla.blubb
6.
7. The Intermediate-DOM
● After Legacy DOM there was a short intermediate phase
● The year we're in? 1997
● The browsers in control? MSIE and Netscape 4.0
● Implemented is the so called “Intermediate DOM”
● MSIE and Netscape place their bets on DHTML
● „Dynamic HTML“
● More APIs to influence HTML via JavaScript
● But still no standard in sight
● Any why would they, it's a browser war anyway
● So we're essentially talking about “DOM Level 0+”
● Still nothing spectacular, a niche in a niche
8. Now, DOM Level 1
● In the year 1998 DOM 1 reached recommendation status
● W3C DOM Level 1. slim but better than nothing
● After 4 years, finally something standard-like emerges
– http://www.w3.org/TR/REC-DOM-Level-1/
● Available components were „Core“ and „HTML“
● “Naming Conventions”
● “Document Structure”
● “Case Sensitivity”
● “Memory Management”
● “Processing Instructions“
● Interfaces defined via IDL
● Interface Description Language, Web IDL
● Still very XML-heavy, no trace of today's HTML
● CDATA, Entities, Notations, etc. etc.
9. Conformity?
● What use is a standard if no one implements it?
● And did browser implement is?
● Nooope. And, as said, why would they.
● document.all in MSIE
● document.layers in Netscape
● elm.innerHTML – first in MSIE then copied all around
● ActiveX and... GeckoActiveXObject (okay, that got canceled)
● VBScript, the language from outer space
● MSIE5 shipped full DOM 1 Support. But tons of extras and deviations too
● Many of which are now also part of the standard
● JavaScript versus JScript again
● Even today we witness relics of that time
● location('vbscript:msgbox(1)')
● location.href = 'javascript:alert(1)'
10. DOM Level 2
● Published by the W3C in late 2000
● http://www.w3.org/TR/DOM-Level-2-Core/
● Enriched with the following modules
● “Core”, „HTML“, „Events“, „Style“, „Views“ etc.
● Better separation of the single satellite standards
● For instance DOM Level 2 Events
● http://www.w3.org/TR/DOM-Level-2-Events/
● Several small but important changes
● document.getElementById() for all document types
● Before that available HTML-only – alternative was „Traversal“ and ”Direct Access”
● Oh yes, and events of course
● „Something happens in case something occurs“
● document.createEvent() etc.
● Otherwise stagnation, over at W3C the climate decreased
● Developers and Browser-Vendors wanted more. Much more.
● And so they just planned and built it in themselves.
11. Features in MSIE5
● A lot of things we consider hip these days
● Favorites, MHTML, Data Islands, XHR, XDR
● ActiveX, WD-XSL, Media Player, Toolbars
● HTA, Conditional Compilation, Active Desktop
● Cursor Capture, own Java VM, XMLDOM
● Bidi-Text, Ruby Characters, Language Encoding
● VML, SAMI, SMIL, CSS Filters, Page Transitions
● DOM Behaviors, WebControls, HTML+TIME
● Media Bar, Radio Bar, Persistence, HTC, TDC
● Scriptable Editing, Viewlink Behaviors, DesignMode
● Many of those disappeared
● Some stayed though
● Others are hidden behind IE's “Docmodes”
12.
13. DOM Level 3
● The W3C continues moving slowly. Very slowly.
● DOM3 meanders into position to take off. Slowly.
● Specified in 2004, so now about ten years old
● Same year, the WHATWG was created and gained ground
● Coincidence? Maybe. Maybe not.
● No more slow-moving, XML-bound W3C?
● Some great ideas by WHATWG, and some less ideal ones
● Web Workers, Web Forms 2.0, “Living Standard”
● DOM3 is still XML-heavy
● XML Serialization, XPath Support
● And finally Keyboard Events
● „The DOM Level 2 Event specification does not provide a key event module.
An event module designed for use with keyboard input devices will be included
in a later version of the DOM specification.“
14. Rise of the Triad
● Prototype
● First release in 2005
● “Monkey Patching”, extending the DOM
● Implements what's missed by developers
● jQuery
● First release in August 2006
● Fast and reliable access to DOM APIs
● Avoiding browser-specific code
– Conditional Comments, CSS Hacks, A Pis
– Conditional Compilation
● MooTools
● First release in September 2006
● OOP in JavaScript
● Extending the Element constructors
● More control over HTML via JavaScript –
yet another DOM so to say
16. The DOM Today
● Specified by the W3C and others as DOM Level 4
● And also by WHATWG, and a bunch of other vendors
● window.btoa() „DOM Level 0. Not part of any standard. Except of course
http://www.whatwg.org/specs/...“
● „Many DOMs“, one goal: API between structure and logic
● HTML DOM
– http://www.w3.org/TR/dom/
– http://dom.spec.whatwg.org/
● SVG DOM
– http://www.w3.org/TR/SVG/svgdom.html
– http://www.w3.org/TR/SVG2/svgdom.html
● PDF DOM
– http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/js_api_reference.pdf
● XML DOM
– http://msdn.microsoft.com/en-us/library/hf9hbf87%28v=vs.110%29.aspx
● MathML DOM
– http://www.w3.org/TR/MathML2/chapter8.html
● And not to forget – many satellite-specs
● http://www.w3.org/TR/#tr_DOM
17. And then JSMVCOMFG
● JavaScript Model-View-Controller Frameworks
● Many developers still yearn for more DOM features
● Web Components coming up slowly. Too slow?
● DOM itself to weak for large scale applications?
● No programmatic templating yet
● No clean separation of code and content
● No good re-usability
● Hard-to-use i18n
● So there's a trend towards JSMVC
● Or jsMvvM or MVW or...
● “Super-heroic Frameworks”
● Extend HTML's powers
● Lock people away the DOM
● Force-feed individual interfaces
● JSMVC Security https://code.google.com/p/mustache-security/
18. But now let's get to it
● We have seen the following
● The DOM developed over more than one decade
● Meanwhile the API is huge
● Sometimes simple and intuitive
● Sometimes complex, counter intuitive and congested
● Still, without the DOM, nothing moves in the modern web
● What we want to see now
● Well, how about the parts where „no one can hear you scream“?
● Where can we find behaviors that are risky
● How can we spot those behaviors
● And when does security come into play?
● Maybe even a small „0ld-Day“ for illustration?
● So, let's get started!
19. String-to-Code
● The DOM is overflowing on ways
to turns strings into code
● Be it HTML or direct JavaScript
● Some of them are classics
● Other not too well known
● Then others rather hidden
● Result? Usually DOMXSS
● Let's have a look at a list of those
● Just as a small warm-up
● And then have a look at more
exotic cases
21. DOM Clobbering
● Not the most well-known attack technique
● Yet pretty effective if the stars are aligned well
● Anyone knows the term already?
● I think it was Gareth who coined it back then...
● There's not too much documentation available
● But the attacks can be fierce and hard to mitigate!
● So, who still remembers the site jibbering.com?
● “Unsafe Names for HTML Form Controls”
● http://jibbering.com/faq/names/
● And that is the very essence of DOM Clobbering
22. “Browsers also may add names and id's of other
elements as properties to document, and sometimes
to the global object (or an object above the global
object in scope).
This nonstandard
behavior can result in
replacement of properties on other objects. The
problems it causes are discussed in detail.”
25. Soooo...
● Some attributes of FORM elements spawn global references
● And often, we can create child properties using certain attributes
● And we can even assign strings to these child properties
● Jibbering.org calls these „Shortcut Accessors“
● http://jibbering.com/faq/notes/form-access/#faShrt
● But it doesn't work in any case of course
● For most browsers, the attribute name must match an existing property
in the element's constructor
● Meaning – FORM knows action but not blafasel
● So we can clobber action - but blafasel we cannot
● Such a disappointment!
● And that's probably the case for each and every browser, right?
● Riiight?
26. No, not MSIE!
● On MSIE, we can also introduce children by using unknown
attributes
● Meaning, properties that are unknown to the element's constructor
● But only if the page is loaded in an older „docment mode“
● Who still remembers document modes?
● Exactly, the “solution” for compatibility problems and broken layouts
● New MSIE, old engine, activate docmode via Header or META tag
There,
IE8 Mode
27. Influencing Docmodes
● So, a page you want to clobber is in Edge-Mode?
● You can just load it in an Iframe in IE8-Mode
● It will adopt the docmode of the parent/top page
● (X-Frame-Options protects: https://cure53.de/xfo-clickjacking.pdf )
<form id=abc def=123>
</form>
<script>
alert(abd.def)
</script> <meta
http-equiv=x-ua-compatible
content=IE=8
> <iframe src=clobber.html>
No dice
Yes
dice :)
32. So, attackers can...
● Use harmless HTML to severely influence the
DOM
● For example to create new properties and child
properties in the global scope
● Overwrite existing variables
● In case they have not been initialized
● Or passed as an argument
● Well, that's fair enough
● But it's getting even better...
33. Again our friend MSIE
● Just for older versions
● But still...
<form id="document" cookie="123"></form>
<script>
alert(document.cookie)
</script>
<form id="location" href="javascript:alert(1)"></form>
<script>
alert(location.href)
</script>
34. DOM Clobbering Attack
● Now, let's have a look at an actual security bug
● It existed for years in the code of a popular RTE
● We're talking about the software called „CKEditor“
“The best web text editor for everyone”
“World class quality”
“High standard of quality”
● Proper level of modesty, always good...
● Let's watch a Demo (PoC below)
<a href="plugins/preview/preview.html#<svg
onload=alert(1)>" id="_cke_htmlToLoad"
target="_blank">Click me for dolphins!</a>
35. The vulnerable Code
/plugins/preview/preview.html
<script>
var doc = document;
doc.open();
doc.write( window.opener._cke_htmlToLoad );
doc.close();
delete window.opener._cke_htmlToLoad;
</script>
36. To wrap it up...
● The attack works for the following reasons
● We have a document.write()
● We have implicit access to opener
● We can influence a globally scoped „variable“
● We actually have full (string) control via <a>+ id
● <a> + toString() = Content of the href attribute
● Encoding peculiarities for window.location help us
– Some browsers encode special characters (Firefox)
– Some do not (IE, Chrome, Safari, Opera, ...)
● Result: XSS via DOM Clobbering
37. One Security Problem
● The whole things points at a general problem
● We do have great XSS filters on the server
● HTMLPurifier, SafeHTML, AntiSamy etc.
● But we don't have much in the browser
● Okay, MSIE has toStaticHTML()
● Then we have XSS-Filters in the browser, IE, WebKitWebKit/Blink, NoScript
● And there's a bunch of hacks and whacks
● Sandboxed Iframes might be a way as well
● Then jSanity.. but it never got released
● So we were like.. let's build something
● CANNOT BE SO HARD RITE!!1
● Just quickly write some client-side XSS filter
38. DOMPurify, a solution?
● So we need a new tool, let's write it
● And solve client-side issues where the happen
● In the client itself. Yeah!
● XSS filter written in JavaScript, running on the DOM
● Simple API. Dirty string in, clean string out
● Why in the client? Because of the „knowledge parity“!
● Servers cannot solve XSS since they don't know the client
● This is fundamentally important! Always keep that in mind!
● The sever can only try to understand the client
● And provide protection as good as possible. But never 100%
● And sometimes there is no server, then what?
● Offline-Applications
● Apps and Widgets
● Web Crypto! Mailvelope for example, PGP in the browser
39. Again, because it's really so important.
Server-side XSS protection cannot guarantee
100% safety. It's impossible by design
41. Protect against XSS. Easy.
● DOMPurify tries to be as tolerant as possible
● Permit everything that doesn’t hurt. Literally everything.
● Very generous white-list
● Known as secure? Is allowed!
● Not sure or unknown? Blocked!
● Available for HTML, SVG and MathML!
● And whatever ?ML people might come up with
● Even works with Shadow DOM, we'll see that later
● Secure default, Config-API for customizations
● Technological base for the tool is as follows:
● document.implementation.createHTMLDocument()
● document.createNodeIterator()
● document.removeChild()
● document.removeAttributeNode()
● Final serialization and return of the sanitized string. Or DOM.
42. The DOM, an old Buddy.
● That all sounds quite easy, right?
● XSS solved in the client. Shwoops, done.
● But the DOM decided to take revenge on us. Back-stabbed us.
● So, a security library must be able to withstand attacks
● And the attacker can use whatever she finds in the DOM
● Peculiarities turn weaknesses, weaknesses turn vulnerabilities
● And vulnerabilities turn into exploits
● And that happened.
● The work on DOMPurify showed us, what incredible mess the
DOM really is.
● Let's now have a close look at that...
43. 1. DOM Clobbering
● The DOMPurify Pre-Alpha was tested thoroughly before release
● And broken several times. Painfully broken too.
● But the first bypasses had nothing to do with XSS
● But with the DOM, its behavior and the weirdness to it
● Which eventually leads to XSS as we already saw
● So, ladies and gentlemen, what would this snippet of markup do?
<div onclick=alert(0)>
<form onsubmit=alert(1)>
<input name=parentNode>123
</form>
</div>
44. 1. The Effect
● Our code used the property parentNode, see below
● This property however does not exist anymore in its original form
● It got overwritten by its own child element!
● child.parentNode === child // wtf, DOM!
● Unfortunately we need the parentNode property
● So we need to... authenticate and verify parentNode
● Is it that child.parentNode === child? Yes? Potential attack!
/* Remove element if anything prohibits its presence */
currentNode.parentNode.removeChild(currentNode);
45. 2. “Clobbering” Attributes
● That was already pretty nasty
● But it gets a lot worse
● As a security-library we of course have to cover HTML attributes
too
● And, if necessary, safely remove them to prevent XSS
● Now let's have a look at the following bypass
<form onmouseover='alert(1)'>
<input name="attributes">
<input name="attributes">
</form>
46. 2. The Effect
for (var attr = elm.attributes.length-1; attr >= 0; attr--) {
tmp = elm.attributes[attr];
clobbering = false;
elm.removeAttribute(elm.attributes[attr].name);
...
● Our code iterated over attributes to find out which ones exist
● And then to check their values
● But what if attributes is suddenly an HTML element?
● Then the code breaks, XSS is nigh
● So we have to go and check again
● if(typeof elem.attributes.item === 'function') …
● Looks okay, right?
47. 2. Yeah, well...
● Our checks looked nice at first, but they were rubbish!
● Because there was another bypass!
<form onmouseover='alert(1)'>
<input name="attributes">
<input name="attributes">
</form>
● Now, the property attributes consists of two HTML elements
● And therefore it's a NodeCollection
● Which then again has the method items() exposed
● XSS! Dammit! So we need an even better check!
48. 3. And it goes on like that...
● We learned that iterating is not as easy as it seems
● In the early phases on DOMPurify, we saw weird
artifacts
● Element has three attributes, two were removed
● Went great for one. Then others turned invisible. And were
not caught by our loop
● All fine we thought, wrote the element back to the DOM
● And „flooop“, the invisible attribute was back!
<div wow=removeme onmouseover=alert(1)>text
49. 3. Gotta go backwards
● We have to remove attributes „backwards“. So starting
with last and iterating on to the first
● Otherwise the browser has to re-sort! And thereby the
index breaks and we have invisible attributes
● Invisible, but still there.
// wrong
for (var i = 0; i <= elm.attributes.length; i++) {
elm.removeAttribute(elm.attributes[i].name);
// right
for (var attr = elm.attributes.length-1; attr >= 0; attr--) {
elm.removeAttribute(elm.attributes[attr].name);
50. 4. Document Clobbering
● Another trick that was used against us was evil
images
● DOM Clobbering at its best, look at this!
<img src=bla name=getElementByID>
<image name=activeElement><svg onload=alert(1)>
<image name=body>
<img src=x><svg onload=alert(1); autofocus>,
<keygen onfocus=alert(1); autofocus>
51. 5. Mutations or mXSS
● Again, mXSS is a huge issue, also in modern browsers
● We know that some properties get mutated and trigger XSS,
invisible to the server
● http://cure53.de/fp170.pdf
● Among those properties are innerHTML or textContent, cssText
● and many others
● And again, DOMPurify could be bypassed using those tricks
<listing>
<img onerror="alert(1);//" src=1><t t></listing>
<img src=x id/=' onerror=alert(1)//'>
123<a href='u2028javascript:alert(1)'>I am a dolphin too!</a>
52. Security in the DOM?
● Doesn't really exist. Yet. We're getting there though!
● The following need to be kept in mind
● DOM Clobbering, verification of properties
● Overwritten and deactivated methods
● Mutating values, mXSS
● Protocol-Handlers using Unicode (weird Chrome bug)
● Iteration in the right order
● Verification of changes. Verification all the time
● Proper reaction to anomalies
● With DOMPurify we came quite far
● But there's no 100% security yet
● And then there's still jQuery and friend, oh noez!
● And that's we we start at zero again. F****g jQuery!!1
54. Facts
● jQuery is obviously used... quite a lot
● About a fifth of all websites worldwide. A fifth!
● jQuery haunted by „Ghosts of XSS-mas Past“
● Remember the debacle around $(location.hash)
● Or $('<svg onload=alert(1)>')
● The $-Factory, that not only selects and wraps but builds a DOM
● And of all properties uses innerHTML and a DIV to map
● But it gets worse
● Let's have a look at the following attack vector
<option><style></option></select><b><img src=xx:
onerror=alert(1)></style></option>
55. And now what?
● Technically the vector is harmless. Cannot execute JavaScript
● And doesn't. And shouldn't.
● But once jQuery is present, things change because jQuery is
„smart“ and wraps for conformity
// We have to close these tags to support XHTML (#13200)
wrapMap = {
// Support: IE 9
option: [ 1, "<select multiple='multiple'>", "</select>" ],
thead: [ 1, "<table>", "</table>" ],
col: [ 2, "<table><colgroup>", "</colgroup></table>" ],
tr: [ 2, "<table><tbody>", "</tbody></table>" ],
td: [ 3, "<table><tbody><tr>", "</tr></tbody></table>" ],
_default: [ 0, "", "" ]
};
56. So?
● Now, our harmless HTML string turns into
something very much different
● Look at this!
// Original
<option><style></option></select><b><img src=xx:
onerror=alert(1)></style></option>
// Result
<select multiple="multiple">
<option><style></style></option>
</select>
<b>
<img src="xx:" onerror="alert(1)" />
</b>
57. And there's even more...
● Thanks, jQuery, for the night shifts.
● DOMPurify now has a „Safe for jQuery“ mode
● But similar craziness can be done using the Shadow DOM
● With the new <template> element for instance
● Although this element technically has child element, we cannot just
iterate over them. Because they are stored on elm.content.
<template id="tpl">
<b>Heya!</b>
</template>
<script>
tpl.childNodes // Is empty, no child nodes
tpl.content.childNodes // Ah! There's our element!
</script>
58. Protect thy selves
● So, what can we do to protect ourselves?
● At the server-side level
● Classic XSS „protection“ is not enough
● ID and NAME have to be removed from user-generated markup
● CLASS can get dangerous, when MVC are mixed in
● Don't even build black-lists, White-lists are the only working approach
● At the client-side level
● Clobbering is the biggest risk so far
● It's easy to get a fresh DOM but hard to keep it reliable
● Clobbering even happens in document.implementation
● Classic XSS Bugs will disappear in the next years
● Direct and indirect attacks against the DOM will become more prevalent
● So better get on track right now!
● The „XSS N1nja L33t Haxor bounty“ party is gonna be over soon
59. Conclusion
● Proper DOM security is hard
● Understanding the DOM is often hard as well
● Traversal fails, transactions fail
● Elements disappear, new elements pop up
● Without a string JavaScript/DOM Debugger you won't get far
● Browsers still do their own thing here and there
● However, first baby-steps were made
● Documentation, Libraries, Browsers actually fix standard deviations
● https://github.com/cure53/DOMPurify
● https://github.com/cure53/jPurify
● Still, we kind of need a community wiki
● And collect all those crazy artifacts in one place
● And discuss the security implications
● Maybe this? https://github.com/cure53/xss-challenge-wiki
● There's new features coming every day
● And the DOM develops fast(er than anything else in the WWW)
60. The End
● Question?
● Comments?
● Thanks a lot!
● And special thanks to all contributors and
breakers of DOMPurify!