BSidesMCR 2018: Practical Web Cache Poisoning: Redefining 'Unexploitable' by James Kettle

good afternoon and welcome to web crack school web cache poisoning have you ever been working away and just noticed something that wasn't quite right maybe you thought that's weird but rather complex I think I'll deal with that later on but when I have more free time for years web cache poisoning has been a vulnerability that people just didn't want to think about it's existed mostly as a kind of theoretical vonner ability are more often used to scare people into patching things or maybe paying out bounties that it is actually proven to exist and for years I lived in fear of web cache poisoning and it's the tourist complexity but recently I found myself in a situation where I had no choice but

to try and discover that actually web cache poisoning is wonderful so today in this session I'm going to share with you practical tools and techniques to detect explore and exploit web cache poisoning I don't know we start with the story of how research came to be because it's quite right generally but for this one time I'm gonna make an exception so I started out about a year ago with a simple plan and a lot of optimism I wrote a talk called around minor to find hidden query parameters i'm idea was I won this I'll find some cool parameters and I'll find some cool exploits and those and I'll give a talk about that and this started out fairly well I found

some pretty insane parameters on some websites but in these parameters in each parameters over and over again the most interesting vaguely serious thing I could find was born old reflected cross-site scripting which is not very exciting I kind of a talk on that so I thought well this hasn't worked out maybe all the core vulnerabilities are actually hiding in cookies so I hacked up my code and I made pram liner also guess cooking it myself doing that and I found something that looks incredibly promising spend about eight hours on that and then grabs Lily nowhere and had to admit that that was actually a waste of time as well and at this stage there was only really one

option left and that was to hack up my code again and make for a minor also guess HTTP headers so I set out doing that I ran that on loads of sites I found all the sites of all sorts of crazy headers but once again all those headers had was a boring old cross-site scripting and cross-site scripting in headers is generally regarded as an exploitable because there's no way for me to make someone else send some random funny header across the maintenance to exploit the only glimmer of hope that remained at the stage was that maybe I could trick a cache into saving these responses and basically turning itself into an exploit delivery mechanism from

my header based exercise and quite unexpectedly that actually worked so first I'm going to talk about what web cache poisoning is and how you can find it then I'll have a look at a bunch of real websites that I was able to catch poison and also do a live demo in a very well-known piece of software and after that I'll talk about how not to get your cache poisoned and then wrap up and hopefully take five minutes of questions why first of all we need a bit of context this talk practice web cache poisoning is not about poisoning the browser caches browsers have built-in caches these and from an exploit point of view from a

cache poisoning point of view they're quite boring I'm not looking at those also there was a really cool attack on the old last year called web cache deception which is about tricking caches into saving sensitive information belonging to legitimate users so that the attacker can access it I'm not going to talk about that that's a different attack it should not be confused with cache poisoning which is about storing delicious payloads in caches to use the cache as an exploit delivery mechanism also in some circumstances you can poison caches using using response splitting by ahead of injection and with malformed requests using request smuggling these are both core techniques but they don't work on very many systems

these days as far as I can tell and I'm not talking about those either finally and most importantly practical web cache poisoning is not theoretical everything every example this entire presentation has is based on a real system where I've proven the web cache poisoning works and often is not even difficult first let's take a quick look at how caching is supposed to work here we've got three users fetching the same resource one after the other this was more some might be an image JavaScript or just some HTML and the cache sees the first user fetching it saves a local copy of it and just serves it up to other users thereby speeding up the users perception of how fast the

website is working so far so good and the cache poisoning what we want to do is send a request to the back-end application that causes a harmful response to come back to us and then we want the cash to save that and serve their harmful response up to other users when they're just browsing the application the first step to achieving that is to ask the question with those first three users how does the cash flow then they're all fetching the same course it can't be doing the bite by bite comparison on the whole HTTP requests that the users are sending because HTTP requests are full of all kinds of junk I like the use of agent if

those uses had a different browser the user agent header would be different than the caching wouldn't work to resolve this issue caches have the concept of cache piece where they say we only care about certain parts of the request and we're just going to ignore the rest so generally they only care about what makes up the euro so the host header and the request line and if anything else is the same is different they just ignore that it doesn't matter so this is fine but it sets us up for the next question which is what happens if something important is not included in the cache key so here we have two requests they're fetching the same URL but using this language

cookie one of them is trying to fetch it in English and one is trying to fetch it in Spanish and that's great that works absolutely fine until you per cache in front of this system because the language cookie probably won't be included in the cache key and that means when the English user fetches this white paper they will end up accidentally poisoning the cache with the English version of the white paper and other users trying to get in other languages will guess end up with the English version obviously that in there is just a nuisance but that's the behavior that we're going to try to turn to our advantage in effect anything that's not part of the cache key is part of the

cache poisoning attacks office so this is the methodology that we're going to use to find and exploit web - poison first of all you have to find an unpaid input or you probably a HTTP header or a cookie now fortunately this step do this manually is a lot of work but I'm releasing parameter as an open source tool the works in both the Pro and free versions of burp suite so everyone can use that and if you run that until that to guess headers or cookies it will do it and it should do a pretty decent job so that will find you hopefully some on key inputs once you found them the next step is just to work

out if you can actually do anything interesting with them before you can do is change the language well that's a lot of him exciting when you're doing these two steps it's absolutely crucial to specify a random hash Buster on all your requests if you don't do this you risk getting a response from the cache rather than from the back-end server and if you get a response from the cache many unhealed inputs will effectively be completely invisible to you I think this behavior is the reason that web cache poisoning has remained so low-profile for so many years even though once you understand it it's not actually very difficult and it's definitely high severity so once you've found your

unhidden put you found you can do something fun with it the next thing is just a training have it saved in the cache and served up to other users now you might find it's already been saved how are you even doing anything but if it hasn't it's probably because the cache is using some kind of low set saying things like I'm only gonna cache URLs with a certain file extension or content type or status code or something like that so you'll just need to reverse engineer what the caching rules up and then find a page on the site that you can successfully poison when you're doing this successful when you're doing that actual poison injection thing you'll

want to stay static safety parameter more on that later so that is all the theory of gas poisoning now let's take a look at what happens when we actually apply that to real websites part of the goal of this section is just to show you that cache poisoning actually works and isn't just some random are but do you think I made up but I've chosen these specific examples to show you some of the challenges that you may run into when doing the cache poisoning and give you some ideas as to how to address those challenges as usual I've exclusively targeted websites that have bug bounty programs and all the demos here all the example sites have fixed the specific

vulnerabilities I'm showing you but the techniques still work on many many websites and frameworks and in these examples I'm exploiting targets using all of the caching on all of the caches you can see here and ultimately this this technique works on all on all caches out there I don't think there's any caches that have any way of preventing cache poisoning so please don't think that just cuz you're using some funny cache that's not here for your safe okay the tip again with we're gonna have a look at Cerreta com makers of a popular Linux distribution so the first thing you'll notice if you look at their homepage is that it doesn't look very promising from the cache poisoning

point of view we've got this header that says please don't cache this response and also there aren't any headers that suggest that they are actually using caching in the first place so it might be tempting just to not even bother trying but that would be a mistake because headers will lighten so if you've one parameter on this that will spot if you specify the X for did host header the value in that header is reflected inside a URL in the HTML in the response so that's our unhidden pub weight what's the most of this attack to try on this input probably cross-site scripting right since it's bloody everywhere so if we talk about short enough it works we can

break out of this attribute we can break out the tag and inject some malicious JavaScript into the spots on the homepage now by itself this is useless because we're only exploiting ourselves here we're fully reliant on the cache to deliver this payload to our victims so to see if that's going to happen we're going to pretend to be a normal user so we're going to send a request to the same URL and without any funny headers just like a normal user would how we're gonna see if our exploit comes back and sure enough it does so wait we just got full control over the home page of Reddit calm I think wasn't very difficult right the only thing I need to

draw your attention to here is this safe equals one parameter that a lighter than blue this is not part of Viacom this is a safety parameter that I've manually specified that means that when we found this for real lots of Red Hat users didn't have boxes pop enough so that's quite important if you're testing something introduction please forget it so we've seen headers will lie to you but they will also tell you useful things so let's pretend that you're a malicious person and you want to poison the real official canonical version of the homepage and attack all the visitors to a site you effectively in a race with the genuine users of that site in order

to get your response cached rather than having their benign the spots cached so you need your first request you need your the quest to be the first to request to hit the cache after the cache entry expires and obviously you can just spam your request lots of times and you'll probably get there but sometimes headers will help you out this so here are we looking at unity3d they make a well-known comes to game engine and the X host header is reflected in site is reflected inside our script source imports so we've got cross-site scripting by that but the interesting thing is these age and max age head taken together those tell us the exact second that this response will expire in

the cash so that tells us the exact second that we need to send to our payload to successfully poison so HTTP headers can give other clues too so this target I can't name them unfortunately but if I cover them who they are I think they're pretty well known anyway they're using fastly for their caching and they're reflecting the export is what I said in a way that has exorcists just like what Ritter had the interesting thing is the very user agent header so that's telling the crash to add the user agent into the cache key so that means this request will poison the cache but it will only poison it for other people visiting the site with the

same web browser as me and this is both a blessing and a curse it's a bit of a headache because if I want to poison the majority of the visitors to the site then I'll need to resend resend this attack with every possible user agent that a visitor might have but on the other hand it gives us the chance to be a bit more creative about who we target so for example imagine that I happen to know that the developers of this website all tend to use Microsoft edge well what I can do is poison this website for everyone who is not using edge and then the developers are going to have a really difficult time figuring out why

everyone visiting their site is getting exploited all right so so far we've seen three websites and they've all been poisoned using basic reflected cross-site scripting but life is not always that easy I hear we're gonna look at a US government website they actually patched this at the day before by presentation which was in the US which was slightly worrying but it is badged so here exported host is being reflected inside this data so we actually but we can't just break out that actually and get XSS because it's been encoded and what we need to do is figure out what this attribute is actually for so in order to do that I set up matching replace for

burps week to add this exported host header to all my traffic and then I just browse the website and Y found was when I loaded certain pages on the site my browser would send a request to the calibrator server trying to fetch some kind of internationalization data from it so using this cache poisoning I can make visitors to date or gov fetch internationalization data from website let's have a look at what the state is supposed to be it's meant to be a mapping of English phrases into the same phrase in other languages and the translated phrase is then just concatenate it straight into the HTML so what I can do is tell everyone use my

internationalization file and then in that file on my server I'm going to translate English phrases into cross-site scripting exploits and then whenever you load a page that has shown more on it my injected exploit or fight this pattern of something where you trick someone into loading JSON from your website and then serve them up serve back malicious JSON in order to get Exorcist is one that I've seen over and over when doing cache poisoning now after that exploit I forgot to delete the head of injection rule in book so book just kept injecting this header into all of my traffic and a few days later when going when I was about to close down book I noticed something

really weird this request had hit the clout waiter server it due to this header but it didn't seem to be coming from data.gov in fact it was quite a mystery where it was coming from because I had this a lowercase origin null header and after some investigation it turned out to come from a core Firefox feature so Firefox has this system called Mozilla shield which is for kind of forcibly and silently installing extensions in the background for research and marketing purposes this is turned on by default in Firefox you might have actually heard of it because it hit the news late last year when Mozilla decided to install a mr. robot extension on millions of computers

worldwide and some people got upset so anyway so yeah if you're you if you're running Firefox when you open up Firefox and like periodically every 30 minutes it sends a polling request that looks like what you can see here and this is fetching a list of URLs and one of these URLs points to a list of recipes which basically specifying what Firefox shouldn't stop and what happened was Burke had injected this exported host header and that had overridden the URLs being returned to me and then Firefox had fetched the recipe list from my website and sure enough this site was using nginx with caching and didn't have that in the cache key so the end was

always I can actually make every Firefox installation on the planet connect him what his site for this list of recipes which was quite exciting so so Mozilla to their credit was smart enough to sign these recipes so what I couldn't do was just make a malicious extension and install that 150 million computers in one go but there were various other things that I could still do so I could replay any old recipes that they'd ever use any extension they'd ever installed by this system I could just force that on every Firefox world right and so if I knew of an extension with a known vulnerability in it I could just force that non vulnerability on everybody also

I could force the Missis a robot extension on everyone which would be hilarious also there were unsigned versions of all of these recipes which were used by Firefox but were used by Mozilla's back-end infrastructure related to the system for developing recipes so potentially using that I could have got a foothold in the infrastructure gained access to the signing key and then got my 50 million powers a botnet I imported this to them and they patched it really quite quickly so another reoccurring theme in cache poisoning is that we'll see something that the first clue looks completely useless like this here on this redacted site which is a well-known computer game the exported host header the value

former is reflected inside the domain attribute of the cookie by itself as far as I know that's pretty much useless also there's another unhidden book the exported scheme header if we set it to anything other than HTTPS causes a redirect to that domain over HTTPS once again by itself uses but if we send both of these headers at the same time suddenly we've got a redirect to a website of our choice so we can convert because this is happening at the server we can do this to any any response on the entire application ISO on this specific site I can veto back post requests in order to steal CCF tokens and I could also once again redirect a

JSON fetch to make them fetch some some malicious that JSON from my site and get Dom XSS now so far we've exploited loads of sites fundamentally because they use headers to create your votes some systems go beyond that and they use headers for internal routing so on good fire calm their website is hosted with HubSpot and HubSpot trusts the exported server header to specify which client you're connecting to now we can't directly exploit this with cross-site scripting because it's encoded what we need to do is go to HubSpot comm register our loading site on HubSpot put a malicious HTML on that site because they let us and then specify my domain when I'm accessing go to Viacom which so

that gets our malicious HTML coming back and then CloudFlare will help me save that and serve that up so using this we could take full control over go TOCOM and any page on anyone else using HubSpot now i reported this to go ty who passed it on to HubSpot who responded to the issue by a permanent in banning my IP address which wasn't very polite but I did check back later on by passing the baton and they have patched it too so if you're using card spot I think you'll probably okay okay this one's my second favorite attack partly because I'm exploiting the security company because they used their own security product on their website so

here below CloudFlare comm is hosted with ghost and ghost are doing something with the exported post tenet if you specify it we just get this meat Oviraptor / Fable so it looks a little like what we just saw on HubSpot but if we try the technique the worked on HubSpot and register ourselves with ghost it doesn't work we get the correct response after a mysterious ten seconds wait but I never figured out the cause off in order to successfully exploit this we need to hit a different part in ghost stuck so what we need to do is register ghost and specify a custom domain name white wife top party and also and then in the exported host

header put our ghost subdomain so this is a domain that they issue all of their clients with and that will trigger a we dive XY domain and that comes from a different part of their HTTP stack and as a result we can over write any response with the redirect to our domain so here we're kind of halfway to an exploit this is great but we need this response to get cached and on this site it was configured to already cache responses with a certain file extensions so I could read over JPEGs and images and suchlike and basically inject my images into other people's blocks which is pretty cool it's not really that serious what we

want to do is hijack to JavaScript import right and JavaScript responses were getting cached but the redirect the ghost was issuing used HTTP rather than HTTP and that meant that browsers mixed content protection or kick in and block this video rect completely preventing the exploit from working and the same thing happen with CSS this proved out to be a really challenging problem I spent ages trying to find out a way to bypass it and ages for trying to find a way to make this protocol use HTTPS instead and I ended up even considering contacting ghost and just asking them to change this to hate it fierce there was a minor ethical issues with that plan so instead I

decided to try and crowdsource a solution I have this hitting game called hacksaw and I put a level and hacksaw that replicated the problem that I'd run into and then I said there's no known solution to this level and if you find it I'll split the bounty with you 50/50 and that led to have a great community response followed by - or some solutions the first one or someone found in Safari if the website you'll be directing to is in safaris strict Transport Security cash in the video met will get upgraded to HTTPS before the mixed content block happens so that will work also latest sound and presented here a couple of hours ago found there on edge you can

issue a 302 redirect over HTTP and as long as that's going into any HTTP URL there just mix content protection or just spectacularly fail that that's a vulnerability niche so Microsoft might want to fix that at some point yes so the end result is if you go to any good ghost posted blog like blog cocktail for their calm in Safari your edge I could execute arbitrary JavaScript and if you go there in any other browser I can hijack images and track you that way a list okay if things start to get more difficult though so here we can only poison this open this og URL meta property we can't break out so we have to find out what

it's for Oh et stands for Open Graph so the point of this property is to specify what happens when someone shares this page on Facebook by the by clicking like a share page share button on this page or just by pasting the URL and Facebook or Twitter or other social media whatever so we can kind of partially hijack shares with this also in order to get this response cached I had to specify this cookie yeah the session ID for some reason and I had to fetch a specific page on the site but I had the right caching headers in the spots but even having done all of this when I tried to share the page it wasn't

getting hijacked and this turned out to me because they were using cloud flare and cloud flare has a lot of caches and I was poisoning Akash near the UK somewhere and Facebook was hitting a cache in Atlanta so I googled cheap VPS servers in Atlanta and I got one and I did the poisoning from there and sure enough that worked so this is a video I had to redact it quite a lot you say you've been oh definitely use your imagination but basically we've got a website well-known computer game you press the share button it ends up sharing my site I've got full control over what happens then amusingly a facebook also caches this for spots so

when I report this vulnerability first they've gotta fix the vulnerability and then they've got to clear they've got approach their CloudFlare cache but even that even after doing that likes on that page is still being hijacked because they just have to wait for facebook's cache to expire as well so it's quite a persistent kind of attack now that was great but obviously hiring a VPS is a bit of a headache if we want to do that every time we want to poison a specific cache so I decided to investigate whether we really needed to do that but now cloud flür have a fantastic feature where if you access CDN cgi slash trace on any cloud for Everest insight you get this

kind of trace page which has some metadata including this Colo line which tells you which cache you've hit and so I did was I'm a little Bosch one-liner because I don't know how to our multi-line scripts and it's since on the quest it sends a request to my target website like with their host header to access this trace page and it routes that request through every single public type of ipv4 address the CloudFlare half so it sends it like a few hundred thousand times maybe and the end result is there I list of which IP addresses I should have ripped my payloads to to poison which geographic regions and basically you can you can use this kind

of two technique on any other caching provider in general I you don't need a VPS as long as you're willing to put in the F of doing a bit recon first all right at this point we've seen many different attacks almost all using some kind of host overwrite I found others using other we live each one off headers like bucket translate and path underscore info but what I want to introduce you to is my favorite header which is the X original euro header this header is designed to overwrite the URL in the request line and the reason I love it is because it's supported by so many services now just by itself even without caching being involved this

header is quite useful so for example on unities website they were my favorite targets in this presentation if we access slash admin we get blocked by by a reverse proxy like varnish having a rule that says block slash admin but if we put slash admin in the X original URL header we can get access to it and I initially found this header because some of my targets were running Drupal and so I reported this sir tuple and their security guys like I can't find any mention of this header in our code base but I can't confirm it works and it turned out that Drupal 8 is using Symphony and Symphony supports this header but Symphony

actually only sports its header because they inherited it from Zent so if you were using if you've got a PHP application and it's built on anything built on Zend or symphony or drupal then you probably support the center and there's a lot of service so what can we do with this header but yeah what one other thing I it works with with X original URL there's also a header called XV right URL it does exactly the same thing so let's say our target has an external cache like every target I've shown you so far what we can do with this header is effectively the place any response with the response to any other path so on triple and symphony and so on

the query string in the X original URL header is ignored but their path is used so we can't do anything fancy with the query string but we can basically swap the paths around so after saying this request if you try and access the unity for education page you get the unity for gambling page which looks like this so that's kind of entertaining and we kill this needing more harmful things like we can swap the change password page for the logout page so you can't change a password anymore but it's really proved how dangerous this header is I need a case study and for that case study I'm gonna use vanilla triple because there's a lot of

people out there so rupal also has an internal cache this has turned on by default and this cache is aware of the ex original URL header so we can't do anything with the parts but my colleague Gareth Hays was helping me out on this and he noticed something wasn't quite right and eventually figured out that Drupal is eternal cache has a bug in how it handles this header if thinks that the query string in this header is used when actually it's ignored so this gives us something there's kind of the opposite of the bug that we just saw we can replace the response to any query string with any other query stream basically if you're

on a page I can't change what page you're on by can over override the query string you've got with anything else so after sending this you just do a search for kittens you get a search results what's not and that by itself is really quite powerful but for generic mass exploitation of Drupal sites we need one more ingredient and luckily triple provides so tuple has this a slightly crazy feature on any response that's a redirect tuple lets you specify this destination parameter which overrides the distillation of the redirect and they try and do some filtering on this to make sure that it's not a cross origin it mean I met to stop themselves from having an open meadow

makes but we can bypass it fairly easily so by yourself this is rubbish white assistant open me direct but this is the last ingredient that we need to start properly exploiting triple cites so I'm gonna look at two Drupal sites first of all business top interests calm here on the sun pages on their site they import JavaScript via of redirect so what we can do is we can use the internal clash poison to change the parameters on that JavaScript import request and what we're gonna do is inject this destination parameter and the end result is anyone who goes to that page ends up importing JavaScript from my website so I get control over their account so that's

cool but we have a line on the fact that business doc Pinterest comm happens to be exploiting happens to be importing JavaScript via me right and we can do better than that so in every attack that we've seen so far we've poisoned the cache in order to exploit the end user like the victim has been the end user that way but on almost all the Drupal installations you've actually got two caches because you've got the internal cache that's turned off by default and then you've got an external cache like varnish or or CloudFlare that basically everyone uses because the triples really sluggish you don't use it so what we can do is we can make we can do two attacks and the

victim of the first attacked is going to be the other cache so the first request is gonna try and poison the internal cache so we we just find any video vector spots on the entire site and then we poison the internal cache by adding this parameter to change it to a redirect to our website by yourself that's not that much good but then we're gonna shift that poison into the external cache so we're gonna send a request that has the same exit visional URL value so I'll fetch that was malicious poisoned response from the internal cache and it will put it in the external cash at a URL of our choice so using this we can poison any of the

spawns from the application with a redirects to our site so for example on unit 1 stored or unity comm the main thing you're gonna do is by unity or get the free version and so if you I can make it so that if you go on there and you click download installer your your browse has got your own unity calm but the Installer is malware coming from my website so let's have a quick live demo which is hoping the work so here we have stocked report I haven't changed anything all I've done is put a cache in front of this and the first thing I'll show you is that if we just take a request to the site I if you run the

latest version of burp it will hopefully it's not working oh scanner spawns to cut yeah it's maybe gonna find it maybe not we're also for a minor okay for my - no still let's see if it works I swear I five minutes ago okay right here we are oh no no no it's still me twice now okay I'm gonna go with the top minor okay we're gonna sell it to guess headus wait come on okay okay well Berbers work so purpose yes they both like so Berbers fouled this is vulnerable to web cache poisoning and also the Ramlila has found the x and x me right no available heather and it's showing you the evidence for it and it's also found

x original URL and it's even parameter has found that it can do cache poisoning parameter will try a new cache poisoning it's pretty fitting this i don't rely on that but it does work sometimes okay so now we're gonna try and basically redo that attack manually on this site so here this response is just OB direct white nothing interesting there so now I'm gonna send a request it's gonna hit the same code path because of this X original URL header but I've added this destination parameter so the goal of this request is the poison the internal cache at that key with avi direct so if I send this yeah great we've got this video X to our server coming back and

then for the next step we want to shift that to the external cash so we're going to leave this header exactly the same so that we get the same response back thanks to the poisoned internal cash but we've changed that so what you can see here is the yellow that we want to poison so if I send this we should get the same response great so now the external cash it's hopefully poisoned finally I'm gonna just resend I'm gonna send that request without any headers to confirm that it's been poisoned and that appears to be working great so now if I go on Firefox and I so I'm just on the normal home page if I press

login then wind up on course with the labs on a fake malicious version of the login page kill I'm glad about what

Thanks there was a coordinated security release for that the week before last so you want to install that probably yeah yeah great defense sorry good for the most effective defense against cache poisoning isn't not in use caching and then the way not a sound like fax cool advice but I think the thing is some people might end up with caching kind of by accident for example they might start using CloudFlare because they want cloud flares DDoS protection because it is very cheap and but caching is turned on by default so why would say is if you're not using caching just turn it off anyway regardless of whether you're intentionally using caching in his spare mind some people may be accessing your

site for corporate proxies or airports in such like even summarize peas and those ISPs will be doing Kashi so in general you're going to want to try and mitigate cache poisoning regardless of whether you have to the intention here using cash now to do that you need to avoid indeed input basically don't intentionally take inputs from HTTP headers and cookies wherever possible also the where the many frameworks will just add in random headers unexpectedly so you'll probably want to audit your application with burps down and we'll program miner in order to try and find out if any weird headers have been snuck in there if you find them ideally just completely disable support for them that's the best

fix if you can't do that for some reason you could potentially configure your cache layer if it exists just to strip these headers out or if you really need these then you could add them into the cache key which will effectively remove them from the cache poisoning attack service there's a bunch of resources online there's an online white paper there's also I believe one or two printed copies of this on the Manchester stand at the moment also power and wine is open source you can grab the source code for that online and install it via the BAP Store and I've also built a cache poisoning challenge into my hacking game so you can have a shot at that to see if

he's really got to grips with this stuff I hopefully have some fun okay three key things to take away are the header based input is inherently dangerous frameworks can hide lethal functionality and just because they're open-source and have millions of users doesn't mean they're secure and cache poisoning is not theoretical I'm going to take five minutes of questions now if you have any more after that just chuck me an email we'll come and talk to me out the back don't forget to follow me on Twitter thank you for listening

thanks James has anyone got any questions yep do most cutting prop C's honor the very response header to to set their cash I would say no I've only seen I've only noticed the one that does it how's that definitely doesn't have you seen this irony of the WordPress plugins because there's a lot of question plug-ins for WordPress for WordPress look at work Billy I'm sure so I found this via this research showed up like hundreds and hundreds of sites and I only had time to actually look at half there's there's a lot there's loved stuff out there that's still vulnerable another interesting Avenue Avenue would be to look at so I exploited Firefox's update functionality basically right and

there's a lot of software out there that has update functionality if you could do cache poisoning on WordPress is update that would think these funny yeah no more for James will give them one more round of applause please