Rotem Reiss - The Missing Piece: Adding Automated RBAC Checks for Authorization in Your Pipelines

uh so it's a lightning stock we got a fast-paced talk with rotten rice who is a product security manager at playkika and he is a Bug Hunter and a code addict your code addict it's better than being a not an addict anyway I had a terrible joke I'm not gonna say it because my daughter is here uh he's a code addict who has contributed to many open source projects that's right such as OAS Metasploit and grafana his shift from infosec into appsec sorry ship from the ship from development to upset was greatly influenced by his security research uncovering Drupal gedon too two dude you hear that and he has found a disclosed multiple CVS and well-known products like elasticsearch grafana and others he believes that organizations should be defendant with an attacker's mindset and that right there is exactly what besides Tel Aviv is all about so rotten also co-organized the first Israeli bug Bounty Community Meetup now please help me welcoming to the stage welcome let's give a warm welcome to rotten rice who's going to talk to us about the missing piece adding automated role-based access control checks and authorization for authorizations in your pipelines did I get that correctly okay it's she she whispered here she told me what's going on okay let's give it one round of applause to welcome life welcome thank you for sharing the stage with my water sure she's quite a diva like her mom all right bye everybody cool so hello everyone I'm super excited to build as Karen said this is my second time in a row in besides Tel Aviv and I hope that it will be a new tradition so let's talk about the missing piece in the CI so just before that time what time I'm leading the product security activities atletica I'm also a bargainter on my spell time um and then open source contributor has Karen already said so I'm going to jump to the next slide so if you still didn't get where you are so we are here to discuss about authorization in your pipelines and this is going to be uh 10 minutes talk so I'm not going to Deep dive into the details so if anyone wants to know more you can reach out to me later um so let's start to talk about authorization first to understand what is authorization in the first place so in authorization we have two main issues mostly one is unprotected resources for example if we have four API endpoints in our application and one of those is API slash admin we want to make sure that this route is only accessible by a specific role by admins of course the second issue that we might have is idle in Secure direct object reference that means that one user shouldn't be able to access another person's data like order or profile or whatever it should be so we are going to focus the talk even more again this is a lightning talk so the focus here is going to be on SAS platforms and why SAS platforms because of multiple reasons one is that usually starts platforms has multiple roles at least let's say admin and a regular user and also they are usually multi-tenant applications that means that we want to make sure that one company can't access another company's data and also the fact that usually startups are behind those kind of SAS platforms on a lot of cases at least and such platforms have the nature to grow fast and to have some huge number of Technologies and to compromise on the security and for moving again fast so let's talk for a sec about the birth of an authorization bug this is not that different from any other software development life cycle in general the first phase is that we have the analysis usually done by the product team and the product team should Define that we have for example a specific functionality and that functionality should be a accessible by a specific role and after that we have the design and development phase where the architecture Tech lead and developer working together to actually develop the feature and after that hopefully to test it before it goes to production but we are going to see that it's not that easy so since every presentation nowadays have to have something with AI so this is my contribution of AI a quote by jgpt but eventually what I'm trying to say is that seeing is believing so let's jump into the demo so for the sake of the demo I created a mini vulnerable authorization application this is available in my GitHub account you can access it and start it if you liked it and this application have multiple API endpoints as you can see on the screen for example API slash admin as I said before and other endpoints that we are going to see we are enforcing the always Texas control during the CI so I'm going to start from the end to the start so here you can see the end result end result is that we have some kind of a documentation as called inner GitHub repository with the always direction to control metrics that defines which API endpoints we have and which are accessible or which should be accessible by the different roles and Persona that we have in this case user and admin again and the results of the test that we have in the CI moreover we can even create a issues it could be zero issues or GitHub issues on a case of a violation from the policy that we defined so how did we do or how can we do that in the CI so I used the almighty nuclei and if someone here doesn't know this great tool so go ahead and read about it but this tool is mainly for discovering vulnerabilities as a vulnerability scanner for things like scripting issues SQL injection or known CVS but it was never intended to be used as a tool to scan things regarding authorization violations or things like that so how does it work the tool in general is using a yaml templates for its work and you might say to yourself okay my developers aren't going to actually create yaml templates when they are developing a new API and that's correct so the the way the time showing here is only one approach which is to use a script type prepared the script asks a few simple questions and then it creates the templates that we need for the authorization checks in the CI and then it looks something like that it keeps the structure of the API in the directory in again our repository everything as code and we can see API and then user address and we have two yaml files one for admin and the second for user with the same HTTP method get so what we are going to do about that so eventually we have for example the route that we want to test API slash admin and we want to get the results whether this past or failed and as you can see here we have the two templates pretty similar to what we've seen on the previous slide and then we have the severity field in the yaml again this is all the structure of nuclei I didn't invent anything new I just used one tool for achieving the whole based access control and I use the severity I kind of abused it even to declare whether this test should be successful or not so in case that the user should be able to access that specific route that I defined the severity will be informative otherwise it can be anything else it could be a medium a critical whatever you prefer and you can even create different severities per case if you want to Define that a specific route is more risky than the other routes that you have in your application you can also see that I used some metadata for my scripts to run more easily nothing to fancy or too complicated and one more important thing is that we are using the match logic in this case to match against the HTTP called 200 but not in all cases this will be the case so we might have a case where admin a request to a specific API will return something for admins and will return a different body maybe even another property or something like that to another user in eye roll or a lower role so you can match the logic and you can do whatever you want as limited by nuclei and there are not a lot of limitations in this tool in general so that's good for us you can see the example of unauthorized request as I said the severity is I in this case for a user and not for admin so did you say CI yes I did so let's see how it runs in the CI so in the CI we have two main interesting Parts the first part is uploading the artifacts of the nuclei scan as an artifact to the workflow that I ran in this case you can see it here and the second interesting part is the role-based access control Matrix as I showed at the beginning so this is the end result of that so let's do a overview on all that to understand the overall flow so we have the developer the developer needs to create a new endpoint they are creating the new endpoint and then they can use the script to automatically add the test to the code and then it will run in the CI by the way I didn't mention but you can even use Swagger annotations or to automatically generate the tests in the CI so I didn't do that in this example that I created but this is for sure possible and in the CI it makes you if we have any Arabic violations in case that we have our back violations it can fail the build and also create a ticket as we said and updates of course they're always role-based Access Control metrics report that report can then be used by the product team so an important piece of that is that product teams not always have the information on which API endpoints they have and what is the permissions Matrix in delsas platform or in their application so here they can use it in an easy visible way to actually understand what they have in their application and in case that the build has passed then it goes live to production or whatever you want to do so just wrap up authorization bugs could be your biggest nightmare especially in such platforms and you might think that it's impossible to cover it in the CI with some automation but that's wrong and I'm here to prove it we didn't talk about idle that's correct if someone noticed but this is because we don't have a lot of time but it is possible and I demonstrated it on some local pocs that I did and of course check out the demo project if you want to contribute to that or to ask questions feel free to ping me there and of course Embrace cultural improvements make sure that your product teams and the developers are working close together to make sure that you are eliminating all the bugs and reducing the risks while designing your products and applications and don't wait once it's already on production that's it thank you if anyone have any questions all right all right all right all right thank you thank you I have to thank you twice why first of all you're a great speaker so thank you for joining us thank you second of all thank you for looking at that camera right there and third of all thank you for sharing the stage with my Autumn sure sure it's my honor thank you we've got a small gift for you all right all right all right this next talk is one that the entire cfp review team was curious to hear and that's why we have at this time of the day so that we the organizers can actually enjoy this talk ourselves so this next talk we have a dynamic duo of two speakers that are going to share their wisdom and their first time speakers so I want you to give them all the love and all the warmth and all the caring that