Once Upon A Flaw: 5 AppSec Stories, And What We Can Learn From Them

so thank you for coming to this talk uh in which I will tell some stories so one Hill uh I'm ready to die on is that whatever uh you can hear uh cyber security can be tough and especially application security which is the field of security I know best it can be tough to understand for Junior developers so for instance this is an extract not even the full page of the OAS cheet on how to prevent uh SQL injections and so uh it's a bit difficult to grasp there are lots and lots of things to learn uh it can also it can also be difficult to prioritize I guess many of them uh have had to negotiate to uh uh make a project

team prioritize security features uh before uh business features and uh there is uh something we as human beings we are flow um there is something that's called the optimism bias which is our tendency to overestimate the likelihood of positive events and to underestimate the likelihood of negative events and so often so of of course we've all heard about flows and vulnerabilities and brides and attacks but as it doesn't happen to us every day uh we have the tendency to think that it always happened to others and not ourselves and in fact it's an evolutionary trait uh We've evolved to be like that if we knew and thought of all the things that could happen to us

uh if just we crossed the road uh we would always uh St home but evolution gave us some weapons to fight these traits and there is one thing that we've dealt with for centuries long before cyber cyber security was even thing is to meet up around the campire and tell the stories to have the other people of the group uh know what dung we had to face and uh how we could uh avoid them and uh so it's even studied by a neurologist and biologist to understand how in an evolutionary way uh we all wired our brain is wired to understand and react to stories and that's something that's uh that I personally like because I grew up with stories

so I don't does anyone here know of of this so it's a French animated series uh in in English it would be called Papa beaver and it's a series in which the the beaver which is the dad he tells stories to his children and at the end of each story there is a m and so the children can relate to it in their own lives and we as as a viewers we can also relate to them in on our own lives so um why am I interested in the storytelling in in cyber security so I work in a company uh which is called theod in which we build web applications so I've been a web developer myself for

many years and uh as I've always been passionate about application security uh I've helped more and more projects uh build a secure products so I'm a noest member in the France Chapter as my accent can tell and uh I am now the C at Theo so one of my job is to help the developers build secure products and for that I like to think of myself as the papa because I tell lots and lots of stories of vulnerabilities and flows and how our developers can avoid them and the first challenge I had to overcome is and I still have to overcome it is that often developers are not very interested in security um there are many

fields in web development such as the speed new shiny Frameworks uh that are really more interesting than uh security and uh and for me security is very fun it's like a game in which you can find flows in uh things that people builds and so one example of that it will be my first story it's not even in a in a web application it's a real life flow and it's how you can send letters via the French post system without paying so there are two features which are really nice in the post system in France you are able to send letters uh without paying them so when you want to pay letters you have you buy stamps and you

stick them to the envelope and that's how you you pay the post but you have also the possibility to uh send the letter without stump and it's a receiver if they want to get the letter who will have to pay the post uh another feature is the post allows you as a user to make mistakes you can write fake addresses or wrong addresses with mistakes and uh if the post is not able to deliver the letter they will send it back to you if you wrote the the sender address on the back so if we combine those two features let's say uh you send the letter uh with a fake address an address you know that

doesn't exist um and on the sender address you write the address of the person you really want to send the letter to so the post will try to send the letter to the fake address as the address doesn't exist it will fail and so the post will return the letter to the person you wanted to send the letter in the first place so it takes a a lot of time and uh there are double uh price as many chance that the letter is lost and today anyway we don't have to do this because we can send mails and it's free but it works um and of course I don't add uh doing it um so security is fun it's fun but

sometimes it's difficult to uh understand there are some vulnerabilities and flows that are hard to grasp and one example of them is unsafe or insecure disabil so um for a long time uh I've known about this but I told myself there is no way that uh some developers uh will trust the the the C cized content and and pass it on the side and another thing that is uh that can be difficult to understand how to design um is alist um so allo list are often always better than Den list um but sometimes it's very difficult to build because uh uh there are lots and lots and lots of items that you want to allow

and sometimes an infinite amount of items that you want to allow and that's why uh few few years ago spring for Shell happened so it's not log for Shell which is very well known it's a a bit less known attack but so it was a vulnerability in the the spring Java framework which would allow using insecure stabilization uh it would allow an attacker to have a remote Cod execution and so how does it work uh it leverages a feature of spring which is called datab binding so it's a feature basically uh it takes the HTTP request of a form it takes all the attributes all the the fields in this form and it passs them to attributes of an object

that you want to handle on the server side and in Java all objects that inherit the object object have access to an attribute which is called the class attribute and if uh you have a AP Cat Project um those this cler has access to other attributes um so what you can see on the second line it's related to a feature in tcat which is basically there for loging purposes but by using that you would be able to uh to build a file on the server so in the example it's called shell. JSP and uh the content is a web shell and so you would be able to execute code AS aner so it was a long time ago in

2010 and at the time they blocked it so they blocked it with this code so they look at the attributes that can be in a form and if they see something that looks like class loader uh they ignore it and it's not mapped in the final object so everything went well until 12 years later uh because a new feature had been uh added to Jaa which is called the modules and so thanks to the modules you have a new way to access the class loader attributes which is not the class. class loer but the class. module. class loader and in the uh fix that we saw they hadn't thought of that and that's what that's

why it's very difficult to design Alo lists because you have to think of all the possible cases uh in the present but also in the future and in the future the the code base will evolve so they fixed it again and uh this time uh they used an alist principle so they if there is an attribute uh behind the class attributes they they say we only uh this they realized it if it contains name and this way they are pretty sure that uh it will not be exploited again so it's a great way to uh introduce developers to uh how it could happen in the real life the civilization and also uh how to do allo

list properly because of course you can enumerate itms but you could also uh do allow list programmatically by uh saying items inputs must start with something or end with something or even use to build

them um so it's very easy as an expert um to do some Theory crafting and think of how things should be done um only by uh thinking but I think it's on the fi uh by having a look at real vulnerabilities that you can find the best ways to uh protect against Sun flows and so one example of that is so imagine you have this xss situation so an attacker is able to fill an a payload the server stores the payload and then when a a user uh visits a page on which the the payload is displayed it's executed in the browser and uh it's passed and executed so you have this flow where do you fix

it so you have many possibilities you could fix it on the client side uh at the place where the the user enters the the input you could do some input validation just before storing it in your database you could also uh uncode the payload in the API so after getting it for the database but before giving giving it back to the browser or you could also uh um uncode it when the page is wondered and so a few years ago uh that's something that happened in evern note so if you changed the name of a picture um attachment in a note and you added some JavaScript in it uh it was executed when you loaded the image in the

notes so they fixed it and they choose to do it uh uh just before the picture is saved and it's a bit uh tricky because uh uh it's something that uh only worked in the desktop application of evernot so not very not really a web application um but that meant that the issue was not really solved because the old notes were still vulnerable and something uh that is more worrying is hikers could downgrade their own version of the ever Notes app and then they were still able to create malicious notes and to serve them to to uh to victims that had made the the upgrade um and so the Final Fix was to uncode all sanitize directly

in the bower and so all users who patched were safe and so uh because of this story uh for many years I thought okay the only way you have to uh fix xss is on the browser side uh because uh uh with this you're sure that all users are safe and uh and it's enough so why would you take the um what what would you fix it at another place but uh a few months ago um so one thing that we do uh that I do in my company is some Go season so I will go and uh talk to One developer one team of developer we will have a look at that project and look at the code and we

will try to discuss how they protect uh against some some flows or some V some vulnerabilities um and we found out that so it's a a react component and you can see here the dangerously set in our HTML so um with the the name you can guess it's dangerous and for those of you who never played with react uh it's the way to bypass the uncoding in react and so to have incess in your application so we okay it's not very important if uh the user is not able to control what is displayed in these components and so um this component was for some structure data so it's used to display a Json LD uh in SEO so such as Google to display

some fancy components directly in the search page um and which is the thing which is really interesting is that this piece of code came from the next JS so the server framework for react uh it came from the next GS documentation so the the developers thought they were safe by using some code of the official documentation but uh it's not the case and it's not the case because um some of the inputs came from commands uh from the Google Maps API so let's uh imagine youer if you added some JavaScript in commment in Google Maps the commment was fetched in the application and the JavaScript was executed in the application so or it would have been

executed because uh Google Maps did uh something that I thought was useless is uncode on the server side directly in the API so uh even if we had not found out about this we would have been protected thanks to Google Maps doing uh doing this so of course we still need to sanitize or en code on our end but thanks to Google we had a defense in depth layer protection um another thing that uh um we can use stories to to uh learn is that exploits are not always uh direct so some vulnerabilities are not directly exploitable but um that doesn't mean you don't have to fix them because uh attackers could be able to chain them to

achieve their goal so for example um some researchers uh found out about uh this cookie in the zoom application uh and as you can see this cookie is related to CSP so I I won't explain detail what CSP are but so it's a a mechanism to prevent xss get another layer in your defensive depth strategy and so uh the fun the fun part is that Zoom used thisy to set up CSP to prevent xss but uh the uh um attackers the researchers were able to find the xss thanks to this cookie so how how does it work U if you uh change yourself the value of the cookie on your browser uh it will reflect in the HTTP

response so uh the N1 is one way to uh configure csps and so the N ones that you put in the cookie would appear in the HTML response and by many trials they were able to build a payload that was uh uh passed and executed in the B side uh so it's pretty useless because so it's what we call a self xss you have to yourself go in your Dev tools change the value of the cookie and then reload the page and then you have the EXs so to exploit it in the wild um you would have to convince someone to change and there are two kinds of people the people who do do not know uh how to do

it uh but um uh who who do not know the impact but they do not know how to do it so it will be hard to make them do it and uh people who um uh know to do that but they know the impact and so they won't be convinced and there is something called the same Orin policy that prevents you um as a user to modify cookies in another domain but uh the researchers found out a second EXs in another subdomain of Zuma so they didn't give the the real name of the subdomain they called it reed. zoom. us but they were able to uh with a form to inject JavaScript and it's not really

exploitable because nobody had an account on this subdomain and there was no sensitive information but as it's a subdomain of Zoom um they were able to craft a full payload in which they which they were able to change the cookie of the first vulnerability and so by delivering a link of a website they control with this form uh they were able to uh have a full access in Zoom so uh how you can uh leverage it and does it really work to tell stories um so at to uh we send once every few weeks we send the newsletter and um to all emplo in which we tell one of those stories we explain how it happened and how the developers

could have protected themselves and um one of the story we told is once again it's uh it it's related to the post so in France one day people started receive this in the inbox so it it seems like legit receipt from the post and in it you had a link and a QR code and both of them would redirect you to the official post uh website but if we have a look but a look at the URL it's URL encoded uh if we decode it it looks like that and in it you can see a switch site which can make you think of n r and uh this which looks like another link which is not as safe as the post the post

one um so in fact you ended up because of the open R Direct on the pirate sit with a fake login form and so you could give away your credentials and so we told these stories and the literally the day we sent it we got that answer thank you following your email Oran hased this vulnerability in our product which contain thect so it's a big r for us um so the developers understood the ver they found out that they had it in their application and they fixed it right away um so of course it's a bit of luck so to fight the luck when is to have a lot of stories to tell uh so that you

have stories for every ver or flow that you could have to train Developers for um and the more so because there is something that in France we call kilometric death which is a the more an event is close to you and the more impact it will have on you as a as a as a person so for example if one person dies just in your building you will uh uh it will have a great impact on you but if it's two or 3,000 km away it will have to be more and more Debs um so I don't have time um for the uh so I had two bonus stories but uh you can go and speak to me after afterward

uh to so it's about how you can leverage your own personal stories to touch more people um the key takeways is so stories can help developers understand that security is fun it can help them understand and remember flows and Bs it can help settle debates even make you yourself evolve uh you can use it to fight the optimism bias it can help you make security a priority and uh with developers Ingenuity because if they really understand what they up against they will find better tools to fight against that um so the newsletter I talked about it's we send it even outside of too so it's currently only in French but if many of you are interested uh we could be

interested to translate it in English so don't hesitate to come and tell me and we will um release a book with those stories uh later this year so uh uh if you're interested in English translation it's the same come and tell me about it um feel free to give your feedbacks here's my LinkedIn if you want to connect uh the link of the newsletter and the book If you have any questions two questions two one of these fish that's a good question yeah I got a question I say you know for stario so say with self accesss okay you've got you got your infrastru set up you knowability scanners you know you got web traffic if

you push like self say got inside the FR and that concerning your company for the self ex po scenario if someone knew how to do that and did it maliciously could you audit that or is it like as in then that script if that makes sense I know it's a broad question like say someone had a s accs vulnerability they knew the vulnerability they used it to do something within the company to maybe get thatal access would would would it be obvious in C tools we have today that makes sense um do you mean is it able for an Insider to leverage self access they had vable or you know they have access to that xss and they could go into

development console run it so it will uh uh inject the JavaScript but in their own session only in the own session so to you be to collect it on no if it's uh if it can be displayed on the uh web pages of another user then it's not really a self acccess the fact that it's a self acccess is because you change your cookie on your browser and it only affects your browser uh just after so uh there are other ways to use selfix SS uh for instance with cash poisoning where you will store the self xss directly in the cache uh but uh a self xss just in itself it's very difficult to yeah yeah

that's I mean I just wondering and I say it's like is it would it be it probably wouldn't because of yeah okay thanks sorry just just yeah as we saw it doesn't mean you don't have to to fix it I so what sort of resources would you recommend for for me I'm a student would you recommend for I guess

courses so uh what I uh learned with is all the resources made by o all the resources made by oasp to open worldwide applications project uh they have many projects such as the top 10 uh asvs which stands for application security verification standard which is very exhaustive uh and they also uh use to have some tools uh I I often use in my job a proxy called zap Z POI Z attack proxy which is a former a project and uh which is very accessible and can help understand more and more about how AB works thank you for listening and don't hesitate to