The document discusses securing web applications. It argues that traditional approaches like blaming developers or banning third-party cookies are not effective solutions. Adding random tokens manually to URLs is difficult for developers. Using the referer header is unreliable due to inconsistencies across browsers and plugins. The origin header has similar problems. The document proposes an "interpreter suicide" approach where JavaScript detects cross-site navigation and prevents further execution to block attacks. This provides a client-side way to enforce session context without requiring manual token management.
Why isn't infosec working? Did you turn it off and back on again?Rob Fuller
BruCon 2019 Keynote -=> My name is Rob Fuller, I've been around a bit, not as long as some but longer than others. From the US military to government contracting, consulting, large companies, tiny startups and silicon valley behemoths, from podcasting to television, I've had a storied and humbling career in infosec. Let’s get past complaining about blinky lights and users. Let’s talk about what actually works and what doesn't.
Dirty Little Secrets They Didn't Teach You In Pentest Class v2Rob Fuller
This talk (hopefully) provides some new pentesters tools and tricks. Basically a continuation of last year’s Dirty Little Secrets they didn’t teach you in Pentest class. Topics include; OSINT and APIs, certificate stealing, F**king with Incident Response Teams, 10 ways to psexec, and more. Yes, mostly using metasploit.
Thoughts on Defensive Development for SitecorePINT Inc
Presentation given by Thomas Powell (tpowell@pint.com) and Joe Lima (jlima@port80software.com) - 2-15-2012 covering WebAppSec issues with an emphasis on concerns with the Sitecore CMS platform.
Sorry for any small quirks in slideshare conversion.
Why isn't infosec working? Did you turn it off and back on again?Rob Fuller
BruCon 2019 Keynote -=> My name is Rob Fuller, I've been around a bit, not as long as some but longer than others. From the US military to government contracting, consulting, large companies, tiny startups and silicon valley behemoths, from podcasting to television, I've had a storied and humbling career in infosec. Let’s get past complaining about blinky lights and users. Let’s talk about what actually works and what doesn't.
Dirty Little Secrets They Didn't Teach You In Pentest Class v2Rob Fuller
This talk (hopefully) provides some new pentesters tools and tricks. Basically a continuation of last year’s Dirty Little Secrets they didn’t teach you in Pentest class. Topics include; OSINT and APIs, certificate stealing, F**king with Incident Response Teams, 10 ways to psexec, and more. Yes, mostly using metasploit.
Thoughts on Defensive Development for SitecorePINT Inc
Presentation given by Thomas Powell (tpowell@pint.com) and Joe Lima (jlima@port80software.com) - 2-15-2012 covering WebAppSec issues with an emphasis on concerns with the Sitecore CMS platform.
Sorry for any small quirks in slideshare conversion.
Talk on threats to database security. The title is, of course, deadly serious. Wile E. Coyote & other experts on correctness & security are enlisted to help make key points.
IBWAS 2010: Web Security From an Auditor's StandpointLuis Grangeia
In this talk I will attempt to share my experience of over 10 years conducting Web Application security assessments. I will present the current panorama of Web application security practices and talk about what are we doing well and how we can do better. Also, the Web 2.0 has sparked a “social revolution” of the Web, how can security benefit from that revolution?
Presented at https://www.owasp.org/index.php/OWASP_IBWAS10
Heartbleed Bug Vulnerability: Discovery, Impact and SolutionCASCouncil
Join the CASC Wednesday April 30 for a Google+ hangout on the Heartbleed Bug. We’ll cover everything from what the bug does to how to tell if your site is at risk and how certificate authorities are responding.
Panel of CASC members:
• Robin Alden- Comodo
• Jeremy Rowley- DigiCert
• Bruce Morton- Entrust
• Rick Andrews- Symantec
• Wayne Thayer- Go Daddy
Watch the recording: http://bit.ly/1jAQCtk
Abusing bleeding edge web standards for appsec gloryPriyanka Aash
"Through cooperation between browser vendors and standards bodies in the recent past, numerous standards have been created to enforce stronger client-side control for web applications. As web appsec practitioners continue to shift from mitigating vulnerabilities to implementing proactive controls, each new standard adds another layer of defense for attack patterns previously accepted as risks. With the most basic controls complete, attention is shifting toward mitigating more complex threats. As a result of the drive to control for these threats client-side, standards such as SubResource Integrity (SRI), Content Security Policy (CSP), and HTTP Public Key Pinning (HPKP) carry larger implementation risks than others such as HTTP Strict Transport Security (HSTS). Builders supporting legacy applications actively make trade-offs between implementing the latest standards versus accepting risks simply because of the increased risks newer web standards pose.
In this talk, we'll strictly explore the risks posed by SRI, CSP, and HPKP; demonstrate effective mitigation strategies and compromises which may make these standards more accessible to builders and defenders supporting legacy applications; as well as examine emergent properties of standards such as HPKP to cover previously unforeseen scenarios. As a bonus for the breakers, we'll explore and demonstrate exploitations of the emergent risks in these more volatile standards, to include multiple vulnerabilities uncovered quite literally during our research for this talk (which will hopefully be mitigated by d-day)."
(Source: Black Hat USA 2016, Las Vegas)
When you work with a lot of companies scrutinizing their security, you get to see some amazing things. One of the joys of being a commercial security consultant working for big name firms, is that you get to see a lot of innovation and interesting approaches to common problems.
However, as great as this is, the discrete projects you work on are usually a small representation of the overall company. When you look at the company in its entirety, a familiar pattern of weakness begins to reveal itself. While some companies are obviously better than others, the majority of companies are actually weak in remarkably similar ways.
My work in the attacker modeled pentest and enterprise risk assessment realms focuses on looking at a company as a whole. The premise is that, this is what an attacker would do. They won’t just try to attack your quarterly code reviewed main web site, or consumer mobile app. They won’t directly attack your PCI relevant systems to get to customer credit card data. They won’t limit their attacks to those purely against your IT infrastructure. Instead – they’ll look at your entire company, and they will play dirty.
In this session, I’ll focus on the things that plague us all (well most of us), and I’ll offer some simple advice for how to try and tackle each of these areas:
– Weaknesses in Physical Security
– Susceptibility to Phishing
– Vulnerability Management Immaturity
– Weaknesses in Authentication
– Poor Network Segmentation
– Loose Data Access Control
– Terrible Host / Network Visibility
– Unwise Procurement & Security Spending Decisions
Professional WordPress Security: Beyond Security PluginsChris Burgess
A talk delivered at the Melbourne WordPress Meetup discussing practical advice on how you can add additional layers of security to your WordPress website.
POC Conference 2015
Virtual Appliances have become very prevalent these days as virtualization is ubiquitous and hypervisors commonplace. More and more of the major vendors are providing literally virtual clones for many of their once physical-only products. Like IoT and the CAN bus, it's early in the game and vendors are late as usual. One thing that it catching these vendors off guard is the huge additional attack surface, ripe with vulnerabilities, added in the process. Also, many vendors see software appliances as an opportunity for the customer to easily evaluate the product before buying the physical one, making these editions more accessible and debuggable by utilizing features of the platform on which it runs. During this talk, I will provide real case studies for various vulnerabilities created by mistakes that many of the major players made when shipping their appliances. You'll learn how to find these bugs yourself and how the vendors went about fixing them, if at all. By the end of this talk, you should have a firm grasp of how one goes about getting remote root on appliances.
Search and Society: Reimagining Information Access for Radical FuturesBhaskar Mitra
The field of Information retrieval (IR) is currently undergoing a transformative shift, at least partly due to the emerging applications of generative AI to information access. In this talk, we will deliberate on the sociotechnical implications of generative AI for information access. We will argue that there is both a critical necessity and an exciting opportunity for the IR community to re-center our research agendas on societal needs while dismantling the artificial separation between the work on fairness, accountability, transparency, and ethics in IR and the rest of IR research. Instead of adopting a reactionary strategy of trying to mitigate potential social harms from emerging technologies, the community should aim to proactively set the research agenda for the kinds of systems we should build inspired by diverse explicitly stated sociotechnical imaginaries. The sociotechnical imaginaries that underpin the design and development of information access technologies needs to be explicitly articulated, and we need to develop theories of change in context of these diverse perspectives. Our guiding future imaginaries must be informed by other academic fields, such as democratic theory and critical theory, and should be co-developed with social science scholars, legal scholars, civil rights and social justice activists, and artists, among others.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
1. The Art Of Realism In Web
Defense
Dan Kaminsky
Director of Penetration Testing
IOActive
2. Introduction
• I’m Dan Kaminsky
– This is not a talk on DNS
– This is not a talk on DNSSEC
– This is not a talk on X.509
– This is (mostly) not even a talk about offense
• Though it’ll happen
• We are here to discuss defense
– Why it’s hard
– Why it’s still hard
– How the Web is (still!) difficult to secure in very basic ways
– What technical steps can be taken to make it easier for
developers to secure their sites
3. The Web Has Won
• HTML, JavaScript, and CSS are, by a wide margin,
the most popular programming languages on the
planet, at least for front end design
– Bigger than Win32
– Bigger than Objective C
– Bigger than Java
– Bigger than Flash
• Why install software when you can just browse to
www.kayak.com?
4. The Web Has A Security Problem
• Cross Site Scripting (XSS) and Cross Site Request
Forgery (XSRF) are endemic
• SQL Injection is not going away
– And not just SQL – XML, JSON, even LDAP is in trouble
• These are not new problems. These go back a
decade. Why are we still suffering them?
– After all, we’ve been saying for years, use randomized
tokens in URLs, and “validate your input”!
5. The Traditional Response
• “Developers are stupid and lazy.”
– This is a great response – for our egos
– It defines hackers as intelligent and industrious!
6. The Reality (as I see it)
• It remains too difficult to make web browsers do
surprisingly simple things
– “Dan, I’ve been coming to Defcon for years. I love
security. But you know, it’s $50K for me to build the
site, and $150K for me to get somebody to come out
and secure it. Do you know anybody who will pay 4x
for me to build them a site?”
– Our advice for how to secure things is really
amazingly expensive
• Expensive in terms of dev hours
• Expensive in terms of outside validation
– “So?”
7. Our Message
• “It doesn’t matter if it’s expensive.”
• “It doesn’t matter if it’s fragile.”
• “It doesn’t matter if it breaks things.”
• “It doesn’t matter if it doesn’t even do a great job
securing things.”
• It’s security! Obviously everybody has to do it!
– And so instead of improving our technologies to the
point where security is achievable, we spin our wheels
demanding the deployment of immature defenses
8. You may disagree.
• If you think all our existing solutions are good
enough, and the only problem is lazy and stupid
developers (“insufficiently incentivized” if you’re
an academic), nothing I can say is going to
convince you otherwise.
• But if you agree, then your immediate question
should be: What are you recommending?
– It is not enough to curse the darkness. One must
praise the light!
9. First Law Of Securing the Web:
You are not allowed to break the web.
• This is a point of significant contention!
– Not just about cookies.
• Remember “Mogul”, the huge project centered
around dealing with Marsh Ray’s TLS
Renegotiation vulnerability?
• Remember how it involved an enormous IETF
standardization effort around a fix, and a huge
amount of work?
• Did you notice all the patch announcements of
crypto libraries applying the renegotiation fix?
10. The Fix Is Off By Default In Firefox
• Just like I told Marsh Ray it would be.
• “Note that to benefit from the fix for CVE-2009-3555
added in nss-3.12.6, Firefox 3.6 users will need to set
their security.ssl.require_safe_negotiation preference
to true. In Mandriva the default setting is false due to
problems with some common sites.” – Mandriva Patch
Notes
– security.ssl.allow_unrestricted_renego_everywhere__te
mporarily_available_pref
Current default value: DEPENDS, see end of section
The development version of Firefox (3.7-pre) uses "false"
The stable releases 3.5.9 and 3.6.2 use "true"
As soon as a sufficient amount of servers had a chance to
upgrade, the default in stable releases will be switched to
"false", too
11. Corollary: You Can’t Afford To Wait For
Everybody To Patch
• “The Internet Has No Flag Days”
– i.e. “OK everyone, on July 8th, 2013, we will all
simultaneously stop using Internet Explorer 6”
• They needed to find a way to securely downgrade
for servers that didn’t support their fix.
– They didn’t (maybe they couldn’t?), and ultimately,
it’s now all lost effort.
– When will enough internal servers patch? Never.
– Hard but true.
12. Second Law Of Securing The Web:
Defenses must meet all engineering requirements
• Classical security theory: “The attacker need only find
one bug, while the defender must find them all.”
– This is true, but incomplete.
• Updated security theory: “The attacker need only
consider one engineering requirement, while the
defender must balance them all.”
– If your defense is not fast enough, its not good enough
– If your defense is not compatible enough, its not good
enough
– If your defense is not reliable enough, its not good enough
– If your defense is not usable enough, its not good enough
– If your defense is too hard to build or deploy, its will
probably not be either built nor deployed
13. Security Is (Still!) New
• Security is a new first class engineering requirement
for software
– Power efficiency is a new first class engineering
requirement for consumer electronics
– Just because the TV takes less electricity doesn’t mean it’s
allowed to be any less pretty
– Just because the code is more secure doesn’t mean it’s
allowed to be slow
• There remains surprisingly basic work to be done to
facilitate security
– Building a secure session context is one of those things
– Lets talk about how to do that, while not screwing
everything else up
14. Session Management:
Where We Stand
• How web sites are logged into
– 1) Credentials are supplied
• Generally via a username/password form
– 2) A “cookie” is supplied to the user, so they don’t
have to repeatedly log in
• The cookie is tied to a domain
• All HTTP requests to a domain have its cookie attached
• Requests that come in with these cookies are assumed
to be associated with the “session” created
• The above is pretty easy to code.
15. Third Party Cookies
• Unfortunately, cookies are badly designed for
session management
– THEY LEAK
– Intent: www.bank.com links you from Page A to
Page B, and you don’t have to log back in
– Reality: www.badguy.com links you to the bank’s
Page B, and you don’t have to log back in
– Specific technical fault: Attacker-supplied URLs
are allowed to mix with user-supplied Cookies
16. The “Easy Fix”
• Ban third party cookies!
– “I should only emit google cookies when browsing
google”
• The above would break the web
– All sorts of Single Sign On mechanisms would fall
over
• So this will never happen.
– Reality is what refuses to go away when you stop
believing in it.
17. The “Real Fix”: Add Tokens By Hand
• http://www.site.com/foo.php?tok
en=298371231
– (Or a hidden form element in POSTs)
• Tokens are about sacrificing the automatic nature of cookies
for manual integration of the token in each generated URI
• “Look how easy that is!”
– If you just said that, you are not a web developer.
18. Tokens Are Actually Really Hard
• [All] application local URLs have to be rewritten for using
the randomizer object. While standard HTML forms and
hyperlinks pose no special challenge, prior existing
JavaScript may be harder to deal with. All JavaScript
functions that assign values to document.location or open
new windows have to be located and modified. Also all
existing onclick and onsubmit events have to be rewritten.
Furthermore, HTML code might include external referenced
JavaScript libraries, which have to be processed as well.
Because of these problems, a web application that is
protected by such a solution has to be examined and tested
thoroughly.
– http://www.informatik.uni-
hamburg.de/SVS/papers/2006_esorics_SessionSafe.pdf
19. Tokenizer Tricks Don’t Help Much
• Possible to automatically make relative links inherit the
token
– Randomized domain
• 298371231.site.com
• Martin Johns’ SessionSafe
• That quote came from that page
– Randomized path
• http://www.site.com/2983712131/foo.php
• Actually kind of interesting – first good use for per-path cookies!
• Haven’t heard of this before, but just came up with it
• Absolute links are still very expensive to manage
– They’re very, very common in the field
20. Three Possibilities
• Browsers block third party cookies
– Not happening
• Developers manually add tokens to each HTTP
request
– Barely happening
• Security fails
– Totally happening
– The web is a mess, filled with XSS and XSRF
vulnerabilities
• Even on authenticated resources!
21. A Tale Of Two Classes Of Web Page
BBC News: Needs Deep Linking
Amazon.Com Shopping Cart: Needs
Security From Outside Attackers
22. On Boundaries
• Most natural place to place boundary: Unauthenticated vs.
Authenticated
– Unauthenticated pages are the best landing points
– Authenticated pages expose the greatest complexity
• A strong session context prevents (Reflected) XSS and
XSRF from executing at all
– The attacker just cannot navigate to the endpoint with the bug
– Making entire families of bugs unexploitable is always a good
thing
– If even the unauthenticated landing points have sufficient
complexity that they’re likely to be XSSable, then www.foo.com
can be 302 Redirected to public.foo.com or even
www.foopublic.com.
23. Question
• Is it possible to get secure sessions, without
having to manually append a token to each
request?
24. The Most Common Attempt:
Server-Side Referrer Checking
• HTTP requests can contain a “Referer” field, which is
supposed to describe the URL of the page that sourced the
request for a particular asset
– Yes, it’s misspelled in the standard
• It is possible for an HTTP server to examine every request
that comes in with an authenticated Cookie, and see if it
also comes in with a Referer header from the same site
• Many Content Management Systems have attempted to
use Referer checking to stop XSRF and related attacks
– Developers, finding a defensive technology that is easy and
nondisruptive to implement, will actually do the work!
25. But Wait…
• We tell them not to do this, for “Security
Reasons”
– “Referer headers can be spoofed using XMLHTTP
and by using flash as demonstrated by Amit Klein
and rapid7 and therefore cannot be trusted.”
• http://www.cgisecurity.com/csrf-faq.html
26. Actually.
• Amit et al fixed this years ago
• There is no known mechanism for causing a
browser to emit an arbitrary Referer header,
and hasn’t been for quite some time.
– More importantly, if one is found, it’s fixed, just
like a whole host of other browser bugs
• So can we use this?
27. The Real Reason You Can’t Depend On
Server-Side Referrer: Appcompat
• There are many mechanisms that result in web
browsers navigating from page to page
– Follow an anchor
– Change document.location.href
– Follow a 302 redirect
– Follow a <meta http-equiv=“refresh”> link
– Window.open
• Referer header inconsistently attached – some
methods have the header, some don’t
– Differs by browser
– Really differs by plugin
28. …and that’s without the “security
tools” butting in
• http://codex.wordpress.org/Enable_Sending_Referrers --
how to make Wordpress administration work (at least for
2.0x) if you have any of the following installed:
– Norton Internet Security, Norton Personal, NetBarrier, SyGate
Firewall, Kerio Firewall 4, Zone Alarm Pro, Agnitum Outpost
Firewall Pro 2008, McAfee, Privoxy, etc.
• And that’s to say nothing about network proxies like Squid,
from which about one fifth of HTTP requests are sourced
• Most blocking is there to protect privacy interests or to
protect against Dynamic XSRF attacks, which is reasonable,
but it applies even to Referer headers for the same site
– One security technology interfering with another security
technology? Impossible!
29. Fail Open Openly Failing
• “Can’t we just enforce XSRF protections if there’s
a Referer header, and allow the user in anyway
(fail open) if the header is missing?”
– This is actually the policy of a some CMS’s in the field
– Since there are navigation types that suppress Referer
even on unfiltered hosts (<meta http-
equiv=“refresh”>) they’re exposed.
• See also, HTTPS->HTTP Referer suppression, which is an
intentional feature to prevent full URI leakage from the
secure context (thanks David Ross, Sirdarckat)
30. What About The Origin Header?
• Attempt to “redo” Referer, this time for
security
• Unfortunately, it’s a little complicated…
– Red is when Origin doesn’t work
– Green is when Origin does work
31.
32. NEVER DO THAT TO A DEV
• Origin header tried to incorporate an overly
complex security model
• Result is that it’s effectively random when the
header is applied
– Makes sense if you’re writing a social networking
application, but that’s about it
• Workaround is to rewrite/audit all the links on
your site
– *facepalm*
33. Can We Go Client Side?
• Remember, the client has the actual context,
the server only gets what the client happens
to put on the wire
• Challenge: Can we make it so a violated
session aborts?
– www.badguy.com opens a window to
www.bank.com/badurl. Server supplies the
malicious URL, but the client uses Javascript to
suppress execution
– This would stop XSS
34. Interpreter Suicide
• General idea: Preface all potentially attacker
controlled HTML with a <script> that detects
(we’ll talk about how later) cross-site navigation
• If such is detected, we assume there might be
something unsafe later in the the bytestream,
and we have to prevent the Javascript/HTML
interpreter from ever reaching it
• “We put code at byte 500 so that byte 20000
never executes”
36. What’s Going On
• Renavigation: Assign document.location.href to a safe landing page
– Fires an event to cause the window to navigate
– Does not necessarily stop the existing parse thread
• Replacement: Assign document.body.innerHTML=“”
– Replaces the object into which content was being streamed
• Repetition: Prevent the script block from returning
– Internal: while(1){ i=0; }
– External: Add a dependency on a synchronous call that actually does
block the interpreter for a nonzero amount of time
• What doesn’t work: Releasing
– Calling a nonexistent function only temporarily stops interpretation
– VBScript may still run, along with code in IFRAMEs
• (Thanks, Brandon Creighton!)
37. Why This Works (and it does work)
• <script>
var foo=1;
</script>
<script>
alert(foo);
</script>
• The first script block must return before the
second script block is allowed to execute – in
other words, all functionally correct JS
interpreters must parse HTML blocks linearly
38. What about XSRF?
• Cross Site Request Forgery doesn’t care about the
reply – the reply can be ignored, it’s the request
(when mixed with the user’s cookie) that’s the
source of pain
– What if the reply to the REST endpoint was itself a
batch of JS? And this batch contained a in-session
challenge that, if passed, would result in a second
query with a proper XSRF token?
– What if we only did this, if the requestor’s User-Agent
was a browser?
• Performance impact: 1xRTT (One HTTP round
trip)
39. Appcompat
• Compatibility impact: Some problems with XMLHttpRequest and
Flash
– Both look like browsers, since they “borrow” the browser’s HTTP stack
– Both are mostly same-domain only, with explicit opt-in required for
cross domain activity
– Neither will just automagically execute Javascript
• Could add code to read back the challenge token (from a custom HTTP header,
perhaps), but that’s just as hard as adding a random token
• Could add code to add a random header, but that’s also just as hard as adding
a random token (does save us 1xRTT though)
– Best possible today: Hijack the XMLHttpRequest object, such that all
calls of object.send() are overloaded to add a randomized header
• Should be a similar include possible with Flash’s network stack
• Just figured this out though, so it might not work
• But what test could we use, to determine if we should cut
execution?
40. What about document.referrer?
• Document.referrer is populated in the
Browser DOM, and is read by JS, so nothing on
the wire can suppress it
• However, support for it across navigational
types is more inconsistent than you can
imagine…
42. Could we tag the window object itself?
• Window.name
– Cookie for window, independent of domain
• Window.sessionStorage
– New in HTML5
– Cookie for the combination of window and
domain
– It’s called sessionStorage!
43. Problem: Window Handles
• foo = window.open(“http://www.bank.com”);
• While an attacker cannot read cross domain,
he can navigate the window arbitrarily
– So we’ve gone from “attacker URL, user cookie” to
“attacker URL, user window, user cookie”
• It doesn’t help to tag the window, because the attacker
can drag our window wherever it needs to be
– sessionStorage can’t save us
44. Perspective
• There are major arguments over whether
vector graphics should be animatable
• Meanwhile we can’t safely log into websites
45. Engineering Requirements
• 1) No work for developers on a per-URL basis,
– There are just too many to hunt down
• 2) Both client and server should be able to
differentiate in-session and out-of-session
requests
• 3) Single Sign On support – “friendly” sites need
to be able to log you into anything
• 4) Bookmarks and Top Level Navigation events
must be seen as authenticated (presuming
cookies are still live)
46. One Design
• SessionID “Supercookie”, emitted on requests from:
– Same-site nav
– Top-level nav
– Bookmarks
– “Friend sites”
• API
– window.getSessions([domain]) and
window.setSessionId([string], [domain])
• Google can declare a session ID context for Pandora
• Pandora can see all sessions that are live, from all sources
– window.addSessionFriend(domain) allows/accepts session IDs
from a named domain
– window.atomicnavigate(domain) should do the equivalent of
interpreter suicide, by design
47. The Simple Implementation
• On login:
– window.setSessionId(“loggedin”);
• Server side check: Just look for a cookie pair,
“_sessionId=loggedin”
• Client side check:
if(window.getSessions()[0]!=‘loggedin’){
window.atomicNavigate(‘login.php’);
• (Gets fancier when accepting SSO cookies, but
not much fancier.)
48. Another Thing That’s Broken:
Injection Handling
• "The bottom-line is that there just isn't a large
measurable difference in the security postures from
language to language or framework to framework --
specifically Microsoft ASP Classic, Microsoft .NET, Java,
Cold Fusion, PHP, and Perl. Sure in theory one might be
significantly more secure than the others, but when
deployed on the Web it's just not the case.”
--Jeremiah Grossman, CTO, White Hat Security (a
guy who has audited a lot of web applications)
• Question: Why aren’t the type safe languages safer
against web attack than the type unsafe languages?
49. We Aren’t Actually Using Them
• Reality of web development
– HTML and JavaScript and CSS and XML and SQL and
PHP and C# and…
– “On the web, every time you sneeze, you’re writing in
a new language”
• How do we communicate across all these
languages?
– Strings
• And how type safe are strings?
– Not at all
50. All Injections Are Type Bugs
• select count(*) from foo where x=‘x' or '1'='1';
– The C# sender thinks there’s a string there.
– The SQL receiver thinks there’s a string, a
concatenator, another string, and comparator, and
another string there.
• The challenge: Maintaining type safety across
language boundaries
51. “This is a solved problem!”
• “Just escape your strings”
• “Just use parameterized queries”
• In different ways, both common solutions
suck.
– I hereby declare sucking a legitimate technical
term.
52. What’s Wrong With Escaping
• Escaping fails open.
– If you forget to do it, things continue to work correctly
(most of the time)
– The sooner you find a problem, the less expensive the
problem is
• Escaping works “by coincidence”
– Types are determined in parsed strings by the existence of
terminators (null, quotes, parenthesis, etc.)
– You hope that your escaper catches enough of them
• escape()
• escapeURI()
• escapeURIComponent()
53. Unicode Will Cut You
• Last year, Moxie Marlinspike and I independently broke
most X.509 implementations using a NULL terminator
– “Great! Everybody should know to use a RegEx to alter or
alert on NULLs!”
– What I didn’t say last year, was that there was at least one
other character that I could have used
• 0xC0 0x80 – A UTF-8 overwide NULL, vs. CryptoAPI, also
terminated X.509 Common Names
• You have to mark a special flag to ban overwide characters in
Windows Unicode, and they didn’t.
– And there are up to four other byte sequences that might
also get parsed as a NULL
– To say nothing about “best fit matching”, which can be
different at every tier
– The problem with escaping is that you are, in fact parsing
– and if when you drift from the real parser, you fail
54. Insult To Injury
• Escaping encourages the belief that regular
expressions are a good idea
– b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?).(25[0-
5]|2[0-4][0-9]|[01]?[0-9][0-9]?).(25[0-5]|2[0-4][0-
9]|[01]?[0-9][0-9]?).(25[0-5]|2[0-4][0-9]|[01]?[0-
9][0-9]?)b
• Makes sure that an IP address is valid
– /(<as(?:[^>](?!href))*hrefs*)(&(&[^;]+;)?(?:.(?!3))+(
?:3)?)([^>]+>)/
• Curtis Poe, Author: “I was strutting like a peacock when I
wrote that, followed quickly by eating crow when I ran it. I
never did get that working right. I'm still not sure what I was
trying to do.”
55. What About Parameterized Queries?
• Which would you rather write?
– $r = $m->query(“SELECT * from foo where
fname=‘$fname’ and lname=‘$lname’ and
address=‘$address’ and city=‘$city’”);
– $p->prepare(“SELECT * from foo where
fname=‘$fname’ and lname=‘$lname’ and
address=‘$address’ and city=‘$city’”);
$p->set(1, $fname);
$p->set(2, $lname);
$p->set(3, $address);
$p->set(4, $city);
$r->$m->queryPrepared($p);
• Hint: THIS SUCKS
56. Reality
• Devs hate writing all this boilerplate
– If they didn’t hate it, we wouldn’t have to
repeatedly file bugs demanding they do it!
• Stored procedures demand support from
“priesthood of DBAs” in order to add
functions to the database
– And of course such DBA audits are necessary,
because without them devs will just push in a
magic procedure that can call all other procedures
57. What We’re Left With
• They don’t escape
• They don’t parameterize
• We’re just left insecure
– Can we do better?
58. What About Randomized Terminators?
• Used (reasonably effectively) in MIME
– ------=_NextPart_002_0186_01C89653.D38E9D10 Content-
Type: text/html; charset="Windows-1252" Content-
Transfer-Encoding: quoted-printable
…
------=_NextPart_002_0186_01C89653.D38E9D10—
– Nestable
• Rather than dotting a string with backslashes and
escape codes all over the place, we have a single, fairly
large escape sequence at the beginning and end of
attacker controlled content
– This is portable to other protocols
– I refer to this as “treelocking”
59. (Implicit) Treelocking for XML
• <foo>
<evil>
xxx
</evil>
</foo>
• <foo>
<evil>
<__treelock_EYKPRZEJ2LKF55UJ>
xxx
</__treelock_EYKPRZEJ2LKF55UJ>
</evil>
</foo>
• In this situation, the attacker can inject whatever string he likes – as
long as he never discovers that the escape sequence on this
particular submission is EYKPRZERJ2LKF55UJ, he is stuck inside the
<evil></evil> tree node
60. Caveats
• Requires a parser that cares where in the parse tree sensitive
values show up
– <book>
<title lang="eng">Harry Potter</title>
<price>29.99</price>
</book>
– An xpath search for /book/title will return all titles within books. An
xpath search for //title will return all titles, whether or not they are in
a book.
• xml.findAll(“title”) also fails
– Treelocking cannot save you if you do not care if <evil> provides you
sensitive system data
– Schemas can save you, unless <evil> is allowed to house arbitrary XML
(which it would, if it’s intended to be opaque at your layer)
– This is potentially a problem for SAX parsers and naïve XML
implementations
– Look for this on pen tests that allow you to submit XML, or even
those that accept plaintext but dump it into a n-tier web backend
61. The Larger Problem
• Only works on languages with dynamic terminators
– XML passes
– JSON, LDAP, and SQL do not
• What about encryption?
– {“foo": {
"__treelock_0": {
key: "12341",
locked_data: "abcdabcdabcd"
}
}
• Realization: No actual value to the crypto
– Base64, no crypto: Attacker constrained to string
– Crypto, no Base64: Attacker eventually randomly hits terminators
– Once again, no point to encrypting data when the key is right next to
the encrypted data. Ahem. Everyone, please stop doing this.
62. So, JSON can be handled much like
XML, but adding a de-base64 phase
• Encoded:
– {"test": {
"__treelock_0":
“ImV2aWwiIDogInRvbm90b25vIgo= " }
• Decoded
– {"test": {
"evil" : "tonotono“
}
63. …and this approach can be used for
other protocols, like LDAP and XML…
• LDAP:
ldap://localhost:389/_PL=ABCDABCDABCDABCDABCDABCDABCDABCD
-> ou=ABCDABCDABCD,o=ABCDABCDABCD
-> ou=People,o=JNDITutorial
– Note the intentional use of multiple rounds of Base64
• XML:
<foo>
<evil>
<__treelock_0>
yru9BZ8AEIqm
</__treelock>
</evil>
(yes, I know a CDATA section would theoretically be more XML-y)
64. And SQL too.
• select count(*) from foo where x='x' or '1'='1';
3
• select base64_encode("x' or '1'='1");
eCcAb3IAJzEnPScx
• select count(*) from foo where
x=base64_decode("eCcAb3IAJzEnPScx");
0
65. Alternate Encoding Scheme Discussion
(I’m sure this isn’t the first)
• “I think that easy way to protect against SQL injection is
to convert inputted data into binary format, so that
whatever input is, in sql query it will consist only of 1s
and 0s.”
– Dark.avenger@email.cz, 14-Aug-2008
• “If there IS a 1-to-1 correspondence, then EITHER your
solution only makes it a bit harder to perform a SQL
injection (a hacker would have to figure out what
mapping was used between the text and the 'binary'
format), OR you've come up with simply another way
to escaping your data.”
– jaimthorn@yahoo.com, 13-Oct-2008
66. Base64: The Whitelist to Escaping’s
Blocklist
• select count(*) from foo where
x=base64_decode("eCcAb3IAJzEnPScx");
You know what eCcAb3IAJzEnPScx is not?
– SQL. XML. JSON. LDAP.
– So we’re type-safe going into base64_decode()
• The response from base64_decode is always going to
be treated as a String Literal in the parse tree of the
SQL interpreter itself
– Now, attacker strings are constrained to being just strings,
by the engine itself – not subqueries, not extra lookups,
nothing
– So we’re type-safe coming out of base64_decode()
67. Important Note #1: The Database
Never Stores Base64 Encoded Data
• select count(*) from foo where
x=base64_decode("eCcAb3IAJzEnPScx");
• It’s stored natively – we’re simply using
Base64 between the calling language and the
called language, to enforce a String type
68. Important Note #2: The Remote Client
Doesn’t Generate The Base64
• Early binding: Variables are Base64’d right as
they come off the HTTP header
• Late binding: Variables are Base64’d right
before they are emitted into the SQL parser
• Both of these mechanisms are secure
– Obviously you can’t trust the client to do the
encoding
69. Related Work
• There is some really cool related work done by Meredith Patterson
called Dejector, which attempts to run a second SQL parser in front
of the first one so as to operate filters there
– This works well – especially as a way to execute intelligent filtering and
scrubbing!
– Dejector’s filters, integrated as a plugin to the actual parse tree used
by the actual database, would probably be the best of both worlds
– http://www.thesmartpolitenerd.com/code/dejector.html
• GreenSQL seems to be a productized version of the SQL-parser-
before-the-SQL-parser design; unsure if it’s a filter or a scrubber
– Has had some problems in the past re: parser drift, unfortunately
– Thanks Kuza55!
• The primary difference of this approach is that it is aggressively
trying to find a better interface to/for existing parsers
70. Implementation Notes
• Where to get a Base6*_Encode/Decode function?
– Stored Procedure
• http://wi-fizzle.com/downloads/base64.sql
• Not wildly fast
• Embeds into database
• May require DBA permission
– UDF (User Defined Function)
• MySQL extension, written in C
• Very fast, though not as fast as an integrated function
• DEFINITELY requires DBA permission, and is less portable
• Need to write a good one Wrote a good one at SIGINT
– No performance penalty
– Integration into DB itself
• Surprisingly, doesn’t already exist
• Potential for much greater support across the parse tree
• Would be much faster
71. The Challenge: Debuggability
• Anyone who’s ever debugged an XML-based protocol
(WS-*, ahem) with Base64-encoded blobs in CDATA
sections, from a basic text editor, knows what I’m
talking about
– There are entire protocols that nobody has ever entirely
decoded, because to do so would require key after key
after key which of course notepad.exe can’t be expected to
deal with
– The hope of proposing unkeyed Base64 wrapping as the
one true escaping mechanism is that viewers and
debuggers can be modified to expect to be able to inline-
decode Base6* content with nothing more than the simple
algorithm
72. Possible Necessity
• It may be necessary to adding explicit type
declarations to the Base64 wrapper, so that
text sweepers can find Base64 encoded blobs
and autodecode them, something like:
_-_STRING-AaBbCc-_-
73. The Hook: Ease Of Use For The
Developer
• Developers like string interpolation for porting
variables into SQL, irrespective of security
– Interpolation: $query = "select * from $table where
fname='$fname' and country='$country';";
• Surprisingly, they’ll go to some interesting lengths
to keep their variables near the rest of the query
– Concatenation: query = "select * from " + table +
" where fname = '" + fname + "' and country='" +
country + "';";
– Conjecture: Fitt’s Law (from the UI world) applies to
programmers – the closer data is to the code that
operates on it, the faster the code can be written
74. Editing Interpolation Syntax
• What we could advise
– $query = "select * from bd($!table) where fname=bd($!fname)
and country=bd($!country);“
• We could enrich interpolation syntax by adding inline Base* support
• Couldn’t do this with escaping, because escapes were too specific
• THERE ARE MANY WAYS OF DOING THIS, MOST OF WHICH ARE BAD.
But the core idea seems clearly good – it’s a rough form of marking
type
– Happy programmer
• Who needs to escape anyway, to support Unicode and names with
apostrophes in them properly
– Happy security engineer!
• Maybe even happy DBA, who can enforce use of Base64 on all
incoming String Literals
75. Summary
• 1) Server Side Referer Checking can be bypassed
using navigation methods in every browser
• 2) There are potentially real issues with sensitive
XML elements being parsed out of an attacker
controlled section of a document
• 3) Session management is horribly broken, and
we can do better than manual token integration
• 4) Base64, as a type enforcement system for
strings, might actually be a really good solution
for injections