Bryan Davies: Simple Steps to Build More Secure Applications

[Music]

[Music] thanks everyone for joining me today on my session my session is going to cover simple steps to build more secure applications the um so who am i i'm brian davies i've been doing software development for over 20 years along my career i found a lot of really poorly written code and i'm actually going to show some examples of that today and i'm also going to highlight the stuff i've learned i've also had the opportunity to work on some really cool projects over the years by far the my most uh favorite project was doing a vision system for nortel office phones remember the old meridian phones yeah i worked on some stuff related to them way back when

this was a pretty fun project so in today's presentation what's going on as i mentioned i'm only going to introduce some concepts to build more secure applications the idea is this is stuff you can implement right away it's also meant to be something that all your developers can understand not just your senior guys but it's meant to be also geared towards your your junior staff and so you know yeah like who is this for right it's for anyone who works on code your tech leads you know the tech leads get asked these types of questions so i'm hoping to give them the tools so they can answer these questions and junior devs if they know some of

this stuff it you know it helps them along in their career path as well and they start to know what type of questions to ask so so why why do we even have to do this talk this this is kind of the one thing i've found in my careers i have to go over the same stuff over and over we're really good at focusing on infrastructure for security uh software still playing catch up right right a great example of this is web application firewalls why do we need them if we're so good at preventing sql injection why do we need these firewalls that check every single request that goes into an application right like and that's what we end up

doing is we end up preventing attacks and stuff via infrastructure mainly because a lot of our software is just has these security holes so i'm going to try to show stuff to help plug some of those security holes right and still to this day you'll go to a website and you'll see like a client id in the url like how often do you guys try to change those right i i do i muck with those see what happens and you shouldn't you shouldn't be able to change a client id from one to two and get a different person but you still do we also run into the problem of legacy applications right a lot of them

people just are afraid to change stuff there's bad sql stored procedures buried somewhere in those systems and so there's just problems with those i'm also going to show you some stuff for how to fix that all right so i'm going to jump into it here i'm going to start off with maintainability and this is my opinion but this is something again i've seen over the the year in my opinion maintainability is the most important security feature and it's because if your code can't be maintained it can't be fixed right if there's some sort of login bug yet no one understands how your login code works you can't fix it so maintainability is really really key

right there's also stuff changes all the time all of a sudden a certain uh you know crypto technology might get cracked so now you have to change it in your application well if your code isn't maintainable you can't change it and therefore you're kind of left behind and now you have a website or in a web application that has a known uh hole in it because of the cryptology technology you're using so it's really important to have code that's maintainable you can move it forward because of that so the stuff you know around maintainability you know all the acronyms right you hear those all times those are on like job uh what are they called like the

job boards you see them everywhere you guys know to use source control build servers testable design you know this stuff this is the boring stuff that's why i got the sleepy little panda there it's the boring stuff so stuff i want to go over though code intent this is really really important this is one of the most important things about code maintainability now your dev teams are going to claim well code is self-documenting and yeah it is you can kind of rip apart code to figure out what's going on the problem is if the code has a bug then the self documentation has a bug and essentially the intent is lost and that's really key

right if there's a problem in the code if you look at it well how do you know it's a problem or is the code doing exactly what it's supposed to right you don't know because if the intent is lost you can't make that uh determination so code intent needs to be clear and you know use make use of the header comments uh right make use of inline comments name the class accordingly name the functions accordingly name the variables accordingly and then don't be afraid to change stuff too right if the names are wrong change the names and always kind of remember what it's like to fix someone else's code right all the time you spent cursing them make sure you're

not writing code that ends up with someone else cursing you right fix those things try to include the intent on the code write smaller functions this is one people are getting better at this so but i do want to throw it in here because it is still stuff that you come across where i've fixed code where i essentially had to print out the function and it would be 10 pages long printed and i had to like draw the loops on the printed out paper and basically try to figure these these things out that is a massive paint and so if you can write smaller functions it's easier to maintain it's easier to fix and you know just makes everyone's life

easier no one wants to be scrolling all over when debugging so make these things smaller if you have a smaller function they're easier to replace they're easier to refactor they're easier to kind of change right they're easier to understand and it's really easy to show the intent right you can have a function that basically the name is you know save data and there's three lines of code where it saves the data well that's pretty easy it tells you what it's doing it does it and you're done right so smaller functions really help with maintainability of code levels of abstraction is an interesting one so by this i mean not just levels of inheritance i also kind of mean the call

stack like depth of function calls and what i've seen is i've worked with some developers that can easily hold five levels of abstraction in their mind while they're debugging right or while they're troubleshooting something most can't most are three and that's it and so what ends up happening is if your levels of abstraction are more than three or if your call stack gets way more than three classes deep people get lost and they can't figure out really what's going on and everything gets harder so all of a sudden the maintainability of the app is harder troubleshooting something to find a problem is harder just understanding the structure of the code is harder everything gets harder

so i try to teach my devs to have a rule of thumb of don't go more than three right whether that's again the call stack depth or whether that's an inheritance depth it it seems to work for both cases now there's going to be the odd [Music] timing d do you need more and that's fine but you know don't make a habit of going over it and the other thing you'll find is quite often if it's if you're going over it it actually might be a sign of bad design right like if you have a function that's a controller class that's doing a save method and it calls into the business layer to do save and then

that business layer takes basically a whole bunch of models and saves each one one by one that's not that hard to follow through right it's three levels deep it's pretty easy to understand but if each one of those individuals save calls another save for some other variable or for something else and it starts to daisy chain down then all of a sudden that becomes really confusing for people to figure out and stuff so try to stick to three levels naming is super hard for stuff but dev groups you guys have to figure this out um it's hard work to name stuff it really is but don't be afraid to rename stuff that's one thing i i tend to see over

and over you'll end up with a terrible name for a function and no one will change it they'll just live with this bad name and i mean there's tools to help with this there's refactoring tools or visual studio has refactoring built in there's your sharper there's tons of tools that help you do safe name changes so make use of them right and don't be afraid to change in fact you should change the name if the intent changes so for example if you again going back to my save example if you have some sort of saved data and now it's not saving data it's now just doing a safe check for saving data some sort of pre-check

rename it don't keep it called save data because now the intent is lost right so naming stuff we know it's hard but you know work on it anyways and don't be afraid to rename stuff it's more the renaming that is the thing i want to focus on you don't see that enough people don't correct it avoid clever code i this drives me nuts um there's way too many developers that try to be clever and they have a single function that's doing about 50 different things and no one else can understand it clever code loses meaning it loses intent and it's impossible to maintain so just avoid it right it's just write simple code it doesn't

matter if there's gonna be more objects more variables more calls right you can always go back and do performance checks on it later and clean it up later make it a little bit better performant but if you're initially writing it clever just for performance reasons that's that's actually really bad practice and like i said with no one can maintain clever coats what ends up happening with clever code is it ends up getting deleted after someone spends way too much time fighting with it trying to figure out that it just gets removed anyways so best is just to avoid it there might be exceptions but it's really doubtful that your code is one of the exceptions

um so you know just it's just best to avoid clever code all right i'm going to talk about authentication and authorization now and again the stuff you know again the sleepy panda you know store your passwords hashes and salts don't write your own encryption right and developers know this stuff right you sometimes think about using a good for a user id don't always but just at least you think about it and you kind of know the rule of not using user id one for the power admin right how often do you see that in old sites where the id one is the super duper admin so it makes it a little easier to trick so i can't stress this enough quit

writing your own authentication quit writing your own authorization just quit it there's trusted third-party libraries these libraries are included in frameworks like.net has its own authentication i know java has one like these are already baked in make use of them right there's other options too um start simple and expand right the whole goal of getting the maintainability of code it allows you to start with one of these frameworks i'll use a little bit of it and then if you need more you can swap that piece out for another piece again if your code's maintainable you can do that sort of stuff so it's really important to quit writing your own i really mean it quit writing

your own authentication and authorization i've seen way too many problems with this leaky multi-tenant apps right where you can change the user id right in the url right um i've seen backdoors i've removed this backdoor that i mentioned here where they had a check if the machine name started with dev right the code for developer but guess what we were selling oil and gas software and the target client at the time was devon energy all their machines started with dev so you have these back doors that might have unintended consequences right so you have to be wary of that and if you are writing your own it's easier for developers to sneak these kind of backdoors in

so uh database mistakes the plain text is still common people hate writing encryption decryption codes they end up just not doing it whereas if you use these frameworks it's kind of baked in so you don't have to worry about it right integer based ids that one's not too terrible the reason i include that is because it's really common to use those types of ids in urls and so that's why i'm making that whereas if you use a good you can still throw it in the url but they're a lot harder to guess an a valid one for so that's kind of why i throw the integer based ids and i have an example later of where

some code i came across where char fields were used in username and passwords i'll explain more as to why that's a bad idea the other thing i find with login code is it's written once and never touched the guy who wrote it never ever tidies it up never goes back to fix it it's just written so the idea is like these abandoned github projects have more updates than login code that's in your main application right so it's dangerous to write this code once and then never look at it again whereas if you're using these frameworks they're updated all the time if there's something's been cracked they update it and remove that piece from the from the framework so that's

another reason why they use these frameworks and if you're writing any sort of software that's going to be used by public company there's a chance you can get audited you'll fail the audits with your own hand bombed uh login code so just quit doing it just a bad practice all around and i still see it way too much so another thing i see way too much is the authentication or sorry not the authorization so you're not authorized to do something so they hide the buttons oh the buttons are hidden they can't do anything what about f12 right who doesn't use f12 to kind of unhide buttons or you know remove like a grade over thing on a website right that's

super common so it's just too easy to do that or a fiddler you can actually use tools like that to create your own uh post request and then actually so the buttons hidden doesn't matter i can still send the request to the website so hiding buttons it's not enough so you have to do more right hiding a button does not stop the request so you have to start checking for authorization and authentication on the function call right get in that habit of checking on that stuff in the function call all right so i found this code long ago and so i have to show it it's basically the worst authentication stored procedure i've ever come across

this actually was protecting uh approval system for financial projects worth around five million dollars so i'll kind of jump into the code here a little bit it starts off with there's like searches using wildcards so like username with wrap with wildcards like password that allowed me to actually log into the system using the letter e for both the username and the password and i'm going to hit that sql injection in this if you look a little closely you'll see that this is actually susceptible and i'll come back to that in a bit but yeah in fact i could log in with the letter e and letter e it's kind of crazy if you looked a bit more you could tell

that what this was essentially bad code reuse the stored procedure was not designed for authentication it was actually designed for administration you can see there's a if username is blank or is not blank right and then it jumps in and does this if it's is blank it would jump to the bottom and just return all the users so the idea was this was actually meant to fill a user administration grid and i did dig into it a bit more and sure enough in the app there was a user administration grid that was making use of this code so that's kind of bad code reuse they're trying to use the same stored product for two different purposes

digging into a bit further there was also a bad database design so you'll remember there was like like searches and all that stuff well even if they wrote their own very specific login code they'd still end up using a like search and that's because the database uses n chars so for those who don't know what entire is or char field are the same basically but they're padded with spaces so if you don't use the full hundred characters like this one saying it's gonna be 100 characters long then it fills it with spaces at the end okay and so if you have a like search for your login and a like search for your password because you have this database

design that has padded spaces in it you can actually log into that system using space and space the interesting thing is when you do something like that you get the table return just in the order of the data being in the database as how sql wants to store it and that typically means your admin user which is the first record comes back first so you end up kind of being able to log in as admin using space and space i mean there's a lot wrong with this it's using ids as integers um there's also no encryption that was on this it was just there's just bad all around this one was so i kind of want to point that out and the

reason i want to really point out the database design is because quite often developers inherit a database design and you're stuck working around it and and quite often developers are afraid to change a database design but if you see stuff like this like a char field with 100 and storing you know your username password you have to fix this um there's probably it's probably a low impact you're probably just going to end up there's like trim statements all throughout the code to kind of manage this and you'll just essentially make them um uh not required anymore but it's really important to kind of fix this stuff and don't be afraid to snoop at the database

that's the other thing i see and i'll get into that a little bit where developers are afraid to go past the data layer so that actually brings me to sql injection okay and so the stuff you know that's a classic injection string at the top you know the the sql injection via the url some people have used url parameters and they actually just use it verbatim in a sql call that practice thankfully seems to be going away which is good because that was a really easy way to perform sql injection on websites uh everyone's thought parameters are safe concatenation is bad you know you sanitize your inputs and i don't know most people i know curse using regexes

but you're kind of stuck using them for that sort of stuff i want you guys to learn your orms they're black magic to most developers but it's important that dev teams understand how they work orms hide a lot of stuff and it may be hiding the fact that there's some sql statements behind the scenes that are being used that are actually susceptible to sql injection and you might not know it right you look at the orm like and that's the other thing people are told well if you use norm you're not susceptible to these problems but it actually can be it depends on the database design it depends on the orm design it depends on the business object

design of the orm and i'll show you an example of this where an orm was in front of business objects or sorry sql objects but it was still susceptible to sql injection added bonus if you learn how your orm works it can help with prefer and performance improvement like a good example is entity framework and to list if you look at any kind of orm stuff people call tools way too often and those are expensive hits to the database but again that's a different talk we'll kind of keep going on this orm stuff here next is the data layer dev groups need to learn your data layer again that seems to be kind of quite

often you inherit it and it's kind of black magic you only know what's going on they you're told to use parameters it's really important when you're doing any kind of data layer stuff to also use parameter value types and value size database servers will make assumptions if you don't do that and if they make assumptions you can trick them and i'll actually show you some of that where i trick uh a data layer to assume values i wanted to assume and then of course you want to use the param name in the query string exactly and again i'll show an example of that because that can be kind of meaningless to a junior dev just reading that statement

it's really important to not use sql parameters in string concatenation that's it kind of basically defeats the purpose and this stuff's important so you have to try to review it with your junior devs books don't really do a good job going over this in fact quite often examples and books are incorrect they're just trying to show you how to get the concept across so they kind of show you bad habits all right and it's not just logins over the years i've seen logins are getting better and better being protected people are using the right third party frameworks and so they're actually getting more locked down however search pages are also very susceptible to sql injection and i'm actually going

to show you some stuff here on the side what you can see is what i'm doing on the side here i'll actually get the mouse to show up okay so essentially the top part here what i'm doing is i'm just trying to figure out the width of a search so the idea is i have a search bar where i can just type stuff in and i get a grid of results back okay so i want my first bit of text to be some sort of fake search that brings no results back i want to make sure it brings back nothing and then i union that with a select statement showing a bunch of quotes and

ones the reason i do that is again remember if my parameters aren't explicitly saying what value type that is i can make sql assume that a one in quote is text it'll assume it's almost any um any numeric value and it can also assume it's a date so i can do that in there to kind of bypass any sort of um value type checking essentially and all i'm doing is trying to figure out the width of the query because of course queries tend to have columns that don't show up in the grid and they're hidden like ids and stuff so i'm basically doing this until i get no errors right and now i kind of know by

using this union query that i'm injecting into a search string i kind of figure out the um the width of my grid my search results and now i can do stuff like this where i can include a search for the table names and i mean you don't just have to do sys tables you can do the information schema and the reason this tends to work is because most applications have database owner so i can see anything in the database and so i might not have the sys table i believe you need uh assisted min to run but you might you should still be able to get the list of tables if you use the information schema if your database

owner so now i got a list of the tables right and then i can do the same sort of query below to get the names of the columns within that table and so the idea is you know people aren't always after login information maybe i'm after credit card information in this database right maybe it's something like a home depot site where you don't have to log in but i know somewhere behind the scenes there's going to be credit card information so i can use their general search to find stuff and you can do these types of techniques to find it so it's really important to lock down your search right it's not just the login page

right and so i just want to show you this there there's a few little mistakes in this so it actually won't run as it is but it's this is essentially all you do and i've done this type of stuff on in-house apps before to kind of to teach dev teams how you can attack this stuff and why it's important to protect against it because a common thing is well they can't get the login page we're fine right but you know you have to protect any kind of area where data is being input okay so injectable parameters i mentioned this before you know common thinking is it's a parameter it can't it can't be injected but that's wrong and again this

tends to be something you see more in inherited old applications where this top uh on the beginning where it says bad way this is a stored procedure and this is a string concatenation style storage procedure this style of stored procedure was really common even like 10 years ago like super super common um and that's susceptible to sql injection right that it's you're using parameters but if it puts that parameter in there it just is going to put it in as text so now all of a sudden it can be injectable and so you want to use the way i'm showing below where you're actually using them as variable types and the sql is written out as sql not an execute and

then string concatenation so the trick with this that top stored proc that's a real stored proc i pulled out of an an application i fixed and they actually had they didn't use an orm but but they did have some business logic and some data layers that called this so if you looked strictly at the business layer it looked like it was doing everything fine it was using parameters it was passing it in the parameters were included on the stored procedure perfect it looked totally fine yet it was injectable and that's because when we were digging at it no one thought to look at the sql side no one looked past the orm and that's another common problem and

that's why i mentioned it's good to learn the data layer good to learn the orm because then you know to look past it if you see something and it's injectable you don't just see oh there's no rm we're fine or old parameters we're fine you actually will investigate a bit further and you might find these types of things and a really easy way to find this sort of these higher stored procedures is most sql servers or database servers you can script like a build script that builds all the your database all the all the items in your database so if you generate one of those you can literally then in a text editor just search for three single

quotes and see how many stored procs have those those three single quotes and then you can actually find a lot of stored procedures that might have this problem right and that's what we did where i was working before we actually basically dumped all this to text we did a few searches we found them all and then we started to fix them right and again it was all kind of hidden behind a data layer so no one even knew we had these injectable stored procedures and so we started digging in all right internal framework so this is internal frameworks are the items your dev team builds for your own dev team right and so you'll have tons of these

right everyone has tons of these so again the stuff you know you know you build it you fix it you hate fixing other people's stuff that's where you kind of have these internal frameworks there's some really good books on it framework design guidelines is a great book it's it's more dotnet focused but it's still a really really good book uh patterns of enterprise application architecture that's the martin fowler book that's another really good one for kind of figuring this stuff out i highly recommend both those books when you're building your frameworks you have to design with security in mind now you always hear this right you'll you always hear this talking to any kind of dev or person

that but what does it mean what it means is you need to plan your security right you need to authenticate at access points you need to authorize calls and requests and you need to encrypt your data so i made this little graphic here to kind of help explain that right so authentication that's as a is this user allowed in the application that's what authentication is right even allowed in and so you want to do that you know your sessions your tokens your cookies your login page anything that's kind of impact those you want to check for authentication authorization is more are you you're allowed in the application but are you allowed to do this that's your user

roles right are you allowed to save are you allowed to bring back that data and you want to do authorization checks at your controllers your typically your models right that's more if they're allowed to see the data and obviously your function calls and then the encryption that's a little bit self-explanatory right your transport your database backups are you're encrypting at rest and all that but you need to kind of at least have a bit of a plan right and some applications won't need all this maybe you just need authentication you don't need authorization because it's really simple or maybe you don't need authentication at all but you might need authorization so anyways you just kind of plan

accordingly but it's really useful to kind of know the difference and know the various things and plan accordingly and it's also very helpful to have rules and by that i mean if your dev team knows your authentication rules or your security rules it really helps so for your frameworks for example if i know that this is a controller ui framework but we have a rule the second rule down is that all function calls have to have a an authorization check if it's triggered by the ui it's like okay that makes sense then my little ui focused framework i'll have to have authorization checks in right or if you're writing the data layer and your rule is all functions that save or

retrieve data have to have an authorization check okay perfect i'm writing that layer i'll make sure i put those authorization checks in that layer so if you have an idea of these rules that coincide with that previous drawing then you can kind of come up with a plan and it allows the devs to get a really good understanding of the plan because otherwise there's just a lot of hand waving and talking about this stuff and no one really understands what's going on so it's really really important to kind of have it planned out then there's there's less problems in the future all right the other thing i try to encourage devs to do is push their

security lower and by that i mean if you think of your application as like the layer cake design if your security stuff is at a lower layer then more stuff is forced to go through the security and you only have to write it once okay and so it makes it a little less error prone you don't tend to forget things and it also forces a little bit some interesting practices and i tried to write some code for this to give you the example but it was a bit too tricky so instead i just kind of have a written out example at the bottom and i'll just kind of walk you through it so one place i worked what we did was the

um we had is a multi-tenant application and we needed company id and everything so originally it was the dev the developer sorry the developers had to remember to include where company id equals active company in all their queries that's error prone right you have a developer who's you know tired one day or whatever both go on vacation so his mind's not right there very easy to forget that in a query very very very easy and then you have a leaky multi-tenant application totally by mistake right it's not your hacked it's just someone forgot the where clause and so what we did was on the database repository we added company id as a property and so whenever you use the database

repository by default it grabbed the company id from the user object so there was nothing that the developers had to remember because part of the query was you sent the user id anyways as part of the pro object in the in the repository so it already had the company id and then the other thing we did on the repository help enforce our rules the repository would error out if the company id was blank null or like a special case like for example sometimes people try to send negative one meaning return everything well we didn't accept that if that company id didn't match a company in the database it would error up and that was by design and that was so

there was no possible way that the repository would allow you to get data back for all companies or for the wrong company and so we do stuff like that by pushing it lower now all of a sudden that's completely out of the developers hands the chance of a mistake is greatly reduced right so that's a really important way to handle some of this security all right modifiers okay this is the stuff you know you know the private public you know i don't know about you guys but myself i have to look up everything else in between i can never remember and they're slightly different between languages anyway so it's useful to to look them up

all right so there i've seen so many mistakes with with modifiers especially with this is a common mistake with uh junior developers and i i don't mean to pick on junior developers but it's easy to make everything public and dev teams please stop doing that there's there's so many reasons as to why you shouldn't and start with private and then elevate as required uh there's code analyzing tools that help with this they'll actually say you know maybe this should be public or maybe this should be protected internal or whatever they'll tell you which type of modifier to use and they'll also tell you when you should potentially restrict access and so resharper has some great capability

and visual studio code analyzer has some stuff baked in it as well this is actually really important because it's really easy to make mistakes with these modifiers and so here's just a list of some of the ones that are in between right from private there's protected private internal protected protected internal public and then even static which is kind of a special case but so there's lots of choices it's not just private or public there's lots of choices in between it is worth knowing the difference mainly because it allows you to enforce a good design and i skip a slide uh no okay so i'm going to show you a simple bug and it's all because of code modifiers

being incorrectly used so the top part is the controller code i'm showing both potential calls right where they hit a save button and the intended use is they should call save data safely however you can also call this save data and that's the one that they accidentally called right and if you look at the business logic below the save data safely has a check for save permission so it's just verifying that the user has the correct permissions if they do it's going to call save data this is a pretty standard style design right where it's just as a permission check wrap around a simple save that's more meant to be private now you'll see the save data which just

calls the the save stuff it's public right and in reality in this case it should be private by the way it's designed right so that way the controller code should only be able to call save data safely it should not be able to call save data but because that was accidentally made public it can call it now this type of bug is hard to find because there's no error there's no nothing if you step through the code it reads like it's doing what it's supposed to right oh save button okay i click the save button uh let's see save data yeah saves data it goes to the save data call yeah saves the data all right that's kind of tricky i don't

really know what's going on then you might come across oh wait a second the save data doesn't have a permission check so then here's the gotcha and why code intent is important there's no comments on save data there's no header information there's no information just as database that calls to save the data well that's no different than having saved data as its method name so because the intent is lost it would be really easy for someone to fix this by writing a permission check inside the save data function when in reality the proper fix is making the save data function private because you write that permission check then all of a sudden what you're doing still

going to work but basically all the other places where save data safely is being called you're going to basically do the permission check twice so you've kind of doubled up hits to the database and stuff so so again this is kind of why the intent is important right because in some cases like this you go to fix it you fix it wrong essentially and that might have accidental consequences in this scenario there's not really much for accidental consequences maybe some performance hits but but there is the potential for for problems because the intent is lost and again the other thing i want to point out with the top in the save button click the intended use you know save data

safely if you're starting to type save data intellisense on your visual studio would pick save data the simple one the incorrect one first because it's alphabetical so that would show up first developer would see it you'd see it's public good they'd hit tab they'd move on right so it's another reason why having the modifiers in place actually prevents incorrect use of your code right so it's very important to have that all right process changes so this is like dev process stuff so i'll get into that so again stuff you know you know all the acronyms you know source control build server i hope you're all using source control i i have come across that recently still where companies are not

using source control um so please do testable design integration tests people are already using this they know this stuff really good books on that code complete that's like a classic now which is hard to believe anything by modern fowler tends to be really good and pragmatic programmer of course so most of the devs out there will have will be familiar with those they're great books for this stuff but here's something always admin this is a bit controversial your devs need to be local admin let them have it right this is a common sticky point with it groups especially if they're not a company that's a 100 software development shop those companies tend to be a little bit

more relaxed on this uh if they're another type of company with a dev team internally this is a sticky point but your dev team needs it you can't debug you can't do stuff you can't do half your work without local admin right so i instead plan for it right except that it's going to happen plan for it design for it and by that i mean if for whatever reason if the application you work on requires a tool like a wire shark right wire sharks a packet sniffer allows you to snoop on everything on the network well then designed so that the dev team that needs that system or needs those tools is on a separate network have

firewalls in place to make sure they're not accidentally snooping on stuff in the company that they're not supposed to but you need to plan for it and all too often what i've seen is just no don't use the tool no you can't have admin and then it just causes problems the other thing is devs will find a way right i've even been one of these early in my career where it's like you need a tool you can't get it in well you bring it from home you bring it on a usb stick or in some cases you'll convert it to some other sort of file format or you'll encrypt it and change it and email it in or whatever right

there's always a way to get these files in so it's better to plan for them having admin and accept it and protect accordingly versus making them be sneaky and bring in stuff that you don't want in your network so just like i said it's kind of a controversial issue for some companies so hopefully this is something that can can change the other side of this is if you're going to have admin access on your dev environment you have to handcuff test in uat they have to use the lowest permission possible right no even your integration tests use simple read only use uh standard user do not use your your god mode user um and you need to do that for testing

you have to verify that everything's going to work and you don't want to find out when you're pushing the production that you need elevated access right and typically elevated access is a problem of bad design or the problems misunderstood or something else so make sure you're testing in uat by having the permissions really reduced like as reduced as possible okay that goes for the database too way too often the database account that the application uses is a very elevated account like i mean it'll be database owner it'll be and some i've quite often you still see it's database admin uh and you don't want that so you want to use basically dbree dbright you want

to kind of restrict that access and then in your testing environment try to break your logins right have integration tests a try sql injection have integration tests that try space space no no try to overflow it have tests that don't even use the login page but instead have posts that hit the the service directly or whatever right because that way you're actually testing it not just testing the ui validation so you actually want to hammer the ui uh or sorry you want to hammer the login page on your testing try to break it this is yeah what's in your repo repositories quite often have plain text in the source control plain text password sorry connection strings

that have username passwords private encryption keys all that good stuff typically it's fine typically uh a lot of people tend to have access to your code repository so maybe you don't want to storm there and there's also been a big push lately where a lot of codes being made open source or put on public facing uh code repositories so that external people can see and use it so if you're gonna do that you might wanna just snoop through your code for plain text passwords um other kind of information that can be used against you right like you don't want your private keys out there on a public public repository all right third-party libraries you know

stuff you know you're going to need third-party libraries just just have a process to review them and enforce it right that's really important so devs love free libraries right but you have to be careful are you sure you need it for one who made it uh you know did you check that it's secure and and by that i mean like what i've done in the past is when you're using the library is it calling home right like is wireshark detecting any funny stuff that the library is doing is um is your firewall popping up little things saying hey do you allow access do you want to allow this because quite often there's a reason it's free

right not every person out there is you know just coding for the sake of coding right so sometimes there's some shady stuff out there so be wary of that stuff don't just pick any free library it's in many cases it's better to spend the cash all right a well-built library is worth the money it's maintained it's if there's a security problem with it they'll fix it uh there's there's it's worth it it's really worth it and the problem i've always come across is devs love the free tools i don't know why but they just love them whereas the product managers and security teams they like the really expensive tools but you know so find somewhere in the in the middle there's

probably some cases where you want to spend the money and maybe there's some free ones that are just fine but just have a review process and don't just let the devs put anything in the site um that's very problematic and also make sure your local libraries are in star installed local right you don't want a website where half your libraries your javascript libraries are installed on the provider's website right or you don't want libraries that need to call home like why is it why is it calling home why is it loading some additional files from a different server what's going on there right and so there's a couple reasons for that one is of course it prevents

unwanted changes the the provider of the library isn't changing stuff that then breaks your site but it also prevents manipulation of your application and a great example of that is if you check out troy hunt's uh write-up on the coin hive that i'm not going to get into today but just just google troy hunt coin hive it's an ex amazing example of basically a crypto mining javascript library that was embedded in a ton of free libraries so a ton of websites around the world have this in still to this day and they have no idea it's in there so it's a really good uh article there to check out all right i went over a bunch of useful

tools today i just kind of so i'm just going to touch on them in here just sometimes people don't know the names of stuff so i'm sure you've heard of jetbrains microsoft atlassian but i just did this quick little grid so for anyone especially the junior devs if you heard me say something but you don't know what it is um you know here's a quick little list just so you can see some of the stuff i've used most of these tools that are in here and they're great they're they're make your life way easier you know so here's again it's through some of this is more for the junior dev so i can kind of see where some of this

stuff comes from you know wire sharks a packet sniffer fiddler allows you to muck with web programming and build your own requests and stuff and trace and dot mem from jetbrains are great profiling tools i've used them quite a bit too and speaking of jetbrains resharper is a great tool for junior devs i know like visual studio has some code code analyzing built into it now and it's getting a lot better but i highly recommend resharper for junior guys it it just it highlights problems with the code it kind of teaches you to be a better developer and there's some other tools for from jetbrains too that work with java also for that and with that

that's the end we're kind of a few minutes left for questions so i'm just going to get out of this shared screen mode so i can see the um questions on the chat window so anyway thanks thanks for my talk again my name is uh brian davies and um if you do have any questions after this feel free to email me it's just brian.davies and i'll be more than willing to to try to answer and so let me just check out the chat here oh my goodness a bunch of stuff and i so try to start at the top here wouldn't more functions uh mean more levels of abstraction i'm talking depths of function so and by i'm not talking more functions

that's that's not more levels of abstraction i'm talking about when you have a function that calls a function that calls a function that calls a function and it never walks back out of the stack that gets really really confusing more functions is just more functions just make sure you design them so they're they don't have to be embedded 50 deep to to be called that's what i mean by um levels of abstraction from a function perspective uh your favorite tool for static so what would your what would be your favorite tool for static code evaluation and stuff like this uh i tend to rely on resharper actually resharper does a lot of just highlight stuff as you're typing um

there's they've called like the gutter tool so i really rely on resharper for that sort of stuff um and oh and then someone underneath comments there the tools can be language dependent yeah they definitely are um the stuff from jetbrains which i use jetbrains also has tools for python javascript java they have they even have a new ide called rider that supports all types of languages and kind of has the resharper tool set baked into it so i've been happy with their stuff their stuff to the point where i haven't investigated much else so i apologize i can't really comment on other tools um interviews so there's a bunch of comments on that so yeah there's a bunch

of comments too in the chat about other other checks which is nice to see someone's mentioning something called break man for ruby that's good and sorry my screen just refreshed here is the presentation going to be made available i i i was going to i was going to share the presentation with the organizers i don't know how they're going to share it out that'd be a question for them but i was going to make it available for him because i mean to be fair i think this is something that if you're a tech lead in your group feel free to share this with your junior guys i mean guaranteed you've already reviewed half this stuff with them in some way shape

or form already right but then you get a new junior guy or you get a new intern you've got to go over it again so it's kind of nice to have it as a as a little package if you will um so all right okay i'm just going to hit the q a because i think there's some questions in there too well that's the same one about the functions um and everyone's talking about vi why is my ide i haven't used that one since having the code in unix way back when for school that's a lot a long time ago for me uh any good tools recommended for c sharp stack analysis that's that's still again i kind of rely on the

um the resharper and it's the one thing about resharper is it's not so much a you click a button and here's a report you have to kind of be in the code to see it and i don't really have anything where i've i've announced an analysis with a report i've always just kind of unfortunately done it while i'm in the ide and i kind of see it as i go and so i'm not familiar with the tool for that there's i'm sure there is this one but um uh i just don't know one off top my head so and and yeah and there's a bunch of comments saying great presentation so thank you i'm i'm really happy that you

guys enjoyed it i really hope uh you learned at least something from it i really do and um yeah someone's coming on the devon and that's legit that's not a made up thing that was the sales guys are telling us they already sold devon energy and it's like they did a test install and it just they had super access and it's like what's going on what's going on so we had to we had to dig into that one a bit and it's like oh someone wrote a bypass but um yeah so i've come across some crazy stuff and i'm i'm sure any many of you probably have as well right so any other questions i don't see anything else popping up on

chat but again um my name is brian davies and i'll throw my email in the in the chat like i said if you have any follow-up questions feel free to reach out happy to help um and i've done this type of stuff so much for my internal teams and and stuff it's um it means a lot to be able to get a chance to speak at b-sides and thanks to all the organizers and thanks to everyone attending today that that means means a lot to me so