Coding Blocks - OWASP and You!

Episode Date: November 27, 2013

This week, we talk about OWASP and their list of top 10 application security risks. What they are, infamous examples, and what you can do about it. Download the episode on iTunes or Stitcher and make sure to send us your feedback. Thanks for listening! Show Notes Overview OWASP.org Top 10 culled from 100s organizations, […]

All right, we're live there, drinky drinky. And with that, welcome to Coding Blocks. I'm Joe Zack. I'm Michael Outlaw. And I'm Alan Underwood. And this week, we're going to be talking a little bit about application security, specifically the OWASP Top 10. So OWASP is an organization. They're a 501c3, whatever, nonprofit that are focused on improving the security of software worldwide. And their mission is to make software secure through visibility so that individuals and

organizations can make more informed decisions and just kind of know what's out there. And I think it actually stands for the Open Web Application Security Project. So that's OWASP, kind of like the bug. And what they've done with this top 10 is they've looked at hundreds of organizations, thousands of applications, and over 500,000 vulnerabilities to kind of catalog and gather up and look at what the top 10 threats are based on a variety of things like the prevalence, the exploitability, the impact, and how easy it is to detect these problems. And if you go to their website, they actually have a bunch of books and merchandise on sale so you can read about them, support them, and get a cool hat too. And that's at OWASP.org. Also, I wanted to mention

that a lot of this security development lifecycle stuff and threat modeling stuff that we'll be talking about was developed initially by Microsoft. They literally wrote the books on this stuff. And so a lot of the books, like, literally called Secure Development Lifecycle and Threat Modeling are available on, like, Amazon.com.

Particularly relevant to OWASP are the notions of stride and dread. And what exactly is stride? Are we talking about the acronym here? Yeah, yeah, yeah. Wikipedia says stride is spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. So pretty much what every hacker is trying to do. Yeah, there's different types of attacks.

And DREAD is a way of calculating a sort of numerical score for rating your risk and so what you do is it stands for damage reproducibility exploitability affected users and discoverability so if you had some sort of vulnerability you might categorize in saying the damage is a three out of ten reproducibility is a nine out of 10. Reproducibility is a 9 out of 10. Affected users, 10 out of 10. And discoverability is a 1. That gives you some sort of score back so you can kind of bang these things against each other and sort them and kind of figure out a priority list for your organization. And if you get the high score, your initials stay up there all the way up until we lose power.

And also I want to mention the notion of defense in depth. So we're going to be talking about this OWASP Top 10, and we'll be throwing out a couple of solutions for some of these items. But I wanted to keep in mind that a lot of the stuff that you can do is really based on your environment, and it's not really enough to just have one fix. A lot of these things, there's a lot of different ways in there. And there's kind of a cute saying that's popular saying that the defender has to defend against everything and the

attacker only has to to get one successful attack in order to be successful so uh that's something to keep in mind right so another way of saying defense in depth would be saying not just using strong passwords, but also using roles and permissions. Right, and HTTPS. Multiple layers of security on top of one another. Right, don't rely on the system. Don't rely on the system to do everything for you. You're also going to need to check things yourself as well. Right. And also, one last thing to mention

before we kind of dive in, two last things, is there's a tool called WebGo that's provided by OWASP at OWASP.org that is a purposefully broken ASP.NET web application that's got little exercises that you can do to try and actually kind of break in and see what they could have done differently

to prevent that sort of attack. It's really really cool finally if wanted to mention uh troy hunt at troy hunt on twitter he's actually got a fantastic series looking at the oas top 10 a couple years ago that actually goes into each one in depth and does a great analysis an explanation of what's going on, specifically tailored to.NET. And you can also watch, I think it's like eight hours of videos on a plural site. Yeah, and he can be found at TroyHunt.com. And even though it might be a little dated, it's still good information because these items still stay in the top 10. They might shuffle around, but for the most part, the same vulnerabilities have been hanging around.

Yeah, exactly. I mean, from 2010 to 2013, really, there's been a few things that moved down the list a little bit, and they attribute a lot of that to the fact that it's shown up on the OWASP top 10 for so long. So, yeah, this information is all still extremely relevant. So with that, let's go ahead and get started. Let's talk about the number 10 vulnerability that's out there right now.

Yeah, so we're going to be going through these backwards. Just make that clear. Yeah, countdown. So counting down from 10, unwanted redirects and forwards yeah this one's kind of interesting right we we've probably all seen this at some point and never really thought too much about it but if you ever see in a url you'll sometimes see a url.aspx or.php or something and and there'll be a variable in the query string that'll be like you know redirect to or something and and there'll be a variable in the query string that'll be like you know redirect to or something like that and then it'll have a page in there and that kind of stuff can be hijacked

and send you somewhere that you don't necessarily want to be and so it's really kind of up to your application to make sure that whatever is up there is something that you think should actually happen so you don't you don't want people being sent off to malicious sites. So one of the ways to get around this is to basically have a whitelist, right? Right, and maybe only let you be redirected to your own domain, the domain that you're on, or maybe a whitelist of domains. And I think a good example of this is like if you get an email that says, you've got a Facebook message.

You click on the link, and you're not logged in. so it bounces you to a login form where you log in and then it's got sometimes up in the url maybe or a form field that tells you where to go next basically what action you were trying to take before they interrupted you and made you log in and if this is available to an attacker then they can kind of trick you into going to this login page and then bouncing you to, you know, facebook.cn, which looks like the page you wanted to go to, but is actually, you know, kind of like a keylogger or whatever. Yep. It seems fairly obvious, but it's definitely something that probably a lot of places don't really concern themselves with because they just expect everything to be valid. And pretty much the whole concept behind OWASP and many of these vulnerabilities is that if you don't control the inputs,

then it has to be considered untrusted. So these redirect URLs, these variables, are things that you need to make sure are safe. Yeah, and so as we go through these, we're going to bring up some famous, well-known hacks that happened that relate to these. And I believe the most recent one for this was the Adobe hack, right? Raise your hand in your car, wherever you are, if you were one of the 38 million accounts that were affected. Yeah, that would be the three of us. I know I was. Absolutely.

Speaking of that one, since that one is so current, though, too, we should probably mention that LastPass has lastpass.com slash Adobe. You can actually check to see if your email was one of the ones included in that

hack. Yeah. Unfortunately, mine showed up. Hey, you were there. That's much better than, say, Googling for the Adobe emails. Yes. The places you have to go to get this information are not the places that you should be going. Yeah, you'll probably be flagged.

Yeah. should be going yeah you'll probably be flagged yeah so uh yeah with that one then um we're going to step on to the number nine vulnerability which is using components with known vulnerabilities so i mean honestly i don't think anybody's going to do this on purpose but some of the examples that were given directly from owasp were the Apache CFX authentication bypass. Basically, if you didn't put in an identity token, you had access to every single web service available. That's pretty huge. It might be a feature.

Yeah, I suppose. And then another one that they mentioned was Spring, a very popular Java platform or what do you call it? Not a platform. Geez. Framework. There we go. Yes. There was actually a vulnerability in that that would allow you to take over the server.

Spring is huge. Tons of organizations use it. Tons of Java programmers out there do. It's not necessarily that you're going out of your way to pick anything. You know, OWASP doesn't specifically mention this one, but I would think that the most common one for this would be file formats. There's been some recent. In fact, just this past tuesday microsoft released a big

tiff uh patch fix there have been numerous ones from adobe for pdf files which ironically this oasp documentation was a pdf yeah delivered in pdf there were some other ones too microsoft has had a bunch of well there was there was font ones that have happened. Oh, yeah. They moved stuff down into the kernel layer, and that just brought up a whole slew of stuff. I mean, those are more operating system level, but I don't know. I was kind of surprised that they didn't list that as as one of the components with known vulnerabilities yeah i guess in when they're talking about components i guess they're specifically talking about programming components so you know you don't want to go grab a library that you know has

security vulnerabilities in it but you know chances are you're not trying to do that anyway so i guess the key here is really make sure you keep everything up to date with patches and that kind of stuff right i mean if you go use a third-party library keep it up to date on that you guys aren't going to mention wordpress oh yeah there's been a few of those yeah an old version of wordpress is a sure way to get hacked but even even the newer ones aren't exactly known for being safe and a lot of it's due to the plugins but if someone could could figure out what version of WordPress you're on, that can be an issue. Yep. Well, I mean, if we're going to talk about versions, then that pretty much applies to anything.

Everything, right? Unsupported operating systems. Patch the language you're on. Windows. Version of the server. Keep it all up to date. OS or server software. Which, unfortunately, right, one of the big problems with that, though,

is when you start patching things and keeping things up to date, it inevitably breaks something else you coded, right? I mean, and that's one of the frustrating things, and I think that's why a lot of people don't keep all their stuff up to date. You can't be lazy about it. You have to bite the bullet and do it. It's funny, too. I'm sure everyone's seen that screen where they get an error message on a website, like a bank website or something that says,

MySQL error version 5.01. Right. Oops. Yep. So moving on to number eight, cross-site request forgery. And this is always kind of a weird one to explain but i think it's easiest to just kind of do it through an example um you'll see um you know if you ever notice on amazon.com they make you log in a lot and it's really annoying so it seems to happen uh uh pretty

much every time i try to go add something to my car or go visit orders or something it's like they know i'm already logged in. They know my cart. They know some of my stuff. They know my wish list. But as soon as I try to do an action that, like, takes money or does something that could hurt me, they make me re-authenticate if it's been a while. I'm not really sure what the rules are around it. But they do this in order to prevent someone from kind of slipping me a link that might trick me into, say, adding an item to my cart or adding an item to my cart and checking out. Or if you're a bank, you could actually potentially slip someone a link that transfers money into a counter or something like that. out there was a takeover kind of of uh of google.br for for the brazil version of google

and and what it is is these companies basically faked information being sent to a site so a site expects a certain set of headers a certain payload a certain um url and and essentially what happens is another site knows all the information that that the the that the one site is looking for and in order to do this they generate their own request to that site and they send malicious payloads along with it yeah it was a man in the middle attack yes exactly what it is and it was happening at a at the router level consumer router level it was changing your dns entries to go through it and then acting as the man in the middle to intercept the request that you wanted and behind the scenes it may make a real request it may also do some malicious stuff but well in that case what they were doing is they were redirecting people not to the real google.br but to a to one

that looked very similar and then they were basically installing malware and that kind of stuff on it so so being that they took over the dns they literally it looked like you were at google.br but you were actually sitting on another server out there that was basically putting bad stuff on your computer yeah I think this one could pretty much be summed up with if you have to do anything

secure you want to do it through SSL then that way you can trust the payload end to end yep and you can trust the payload end-to-end. Yep, and you can also do something like pending a URL token, like a unique token per user per transaction, either in the form or in the URL, to kind of verify that that action was expected.

Yeah, so something that was generated on your side beforehand that you expect to get back on the return. Another way that people do that as well is they make sure that you only accept, again, going back to the whitelist, is you only accept requests from a particular domain. So while the man in the middle thing is kind of what they did, they only were able to achieve that because they basically strung together a whole bunch of these things. So if you don't allow external sites to post to your forms or whatever, you need to make sure that whatever post data comes in actually originated from your site. So those are several different ways that you can kind of mitigate this problem.

And that can be pretty tough to do, and I think that's where that unique field comes in. It's just something that you gave the customer that they're giving back to you that you then discard afterwards. So it's kind of like a single-use token or unique to that session. There's actually a wasp actually has a pretty good tool of CRS CSRF tester that can help generate test cases to demonstrate the dangers of CSRF flaws. Very nice. All right. Well, let's move on to number seven missing function level access control.

Better known as authorization, right? Pretty much. So, like, what's an example of this? All right, so one example that was given, I believe, was if you had, like, directory permissions, right? So not allowing them to get into an admin path unless they were actually, you know, authenticated in, right? They couldn't just change their path to be like whatever they wanted.

Okay. Right. And I've seen it before where like the, um, um, like the index page or something in a, in a directory requires you to be logged in, but you don't necessarily have to be logged in to access another file in that same directory because it only checks on that, like the login form. And that also, you know, any sort of application security that makes sure that you're logged in doesn't apply to other things in that folder, like Excel files or text files or, you know, password files or whatever else. Yeah. I mean, we talked about WordPress earlier and while it's not necessarily

part of this particular vulnerability, the, the idea is you can go in and you can look at the entire code base and you know what the admin pages themselves are. So if you actually knew the URL to get there and the authorization wasn't implemented properly, then you could just go straight to the page and do whatever. Um, so that's kind of what this whole thing is, is you know where the page is or you know how to access the thing. And if the authorization is not in place, then you could potentially do things that you shouldn't be allowed to do. So, yep.

Yeah. So the one for that was the famous one for that would be the Apple AT&T iPad email hacks that happened back when the first iPad was released. You know, I mean, Apple kind of gets the bad name for it. on AT&T's side where the hack was happening, where the user could just change the query string and could start farming, harvesting all the email addresses for AT&T-registered iPads. That's unfortunate. And one thing that's bad about this one in particular

is that automated tools aren't very likely to find these things. It really helps to have kind of an insider's knowledge to this. You know, you need to know what those files are, what the technology, file structure looks like underneath. Yeah, so I mean, so that was an example of the two where, like, he had access to do his task, but he didn't have access to start grabbing other people's email addresses too. So, you know, that's a different take on the access level, right? Like you might have access to your stuff, but not necessarily to my account.

Yep. All right. So number six, sensitive data exposure. So there's a lot of different ways this can happen, like storing sensitive data in the clear, plain text. An example I always like to think of is, too, if sometimes sensitive information is logged. Have you ever seen some sort of logging framework that logs all the inputs and outputs to various components? And, oops, you accidentally logged a CV2 number or something like that. I think that would count as sensitive data exposure. So usually the restrictions applied to logs aren't as strict as say the credit

card table. This also applies to like weak or bad crypto. Not sure. One thing I'm not sure about is if this counts for like exposing like the, you know, we talked about my SQL, like exposing version numbers of things. I don't really think that counts as sensitive data here. What do you guys think? Well, I think that counts as server misconfiguration.

I think like one that was talked about was if you, you know, flipping to SSL at the wrong time. So like on your login page, you went across as HTTP, right? And then, so then you enter in your username and password, click submit, and then you'd come back SSL. But by then, it's too late. You already sent everything in the clear. Yep.

Right? So that was already too late. Or another example would be putting sensitive data into the URL. Absolutely. Right? As a parameter in the URL. Well, one of the examples that they give in the OWASP documentation and this one was kind of interesting but let's say that you have credit cards going into the database being encrypted but they're being encrypted at the database

so as they're going in they're being encrypted well to get them back out the database is actually what's doing the decrypting so anybody who gains access to your database can now decrypt all the data coming back out so um that's a really interesting thing to keep in mind is also separating out those layers a little bit so that you know the data can't be accessed right where it lies even though it's encrypted it was a weak encryption. One of the more general versions of this, too, would have to do with passwords getting out, right? Mm-hmm. How to phrase this? the type of encryption quotes that, you know, is used versus hashing, or if it wasn't properly salted, you know,

those have been famous leaks that have happened as well, right? Yep. And one thing to mention about this one, too, is, you know, we mentioned that these are kind of graded, and these top ten come from, you know, combining prevalence and exploitability and detectability, etc. And this is the only one of the top 10 that they list as being difficult to exploit, because that does require having access to those files or the database or whatever. However, I think this one's still in the top 10 because the impacts of having sensitive data exposed are quite severe.

Yeah, this one's huge. I mean, if somebody gets access to all your customer credit cards or social security numbers, if you're a health care provider or something like that, you could almost just shut your doors, right? I mean, unless you're a huge company, that might be a blow that you're not going to recover from. I'm trying to think of what the most recent password hack that happened was. I mean, there was the Adobe hack that happened.

There have been so many. I thought there was another one. I mean, for a while, like, Lowell Second Anonymous, I mean, they were just going to town. They were eating everybody up, yeah. I mean, Lowell Second in particular, I think they did some damage to Sony. But that wasn't this one. Yeah, that wasn't this one. No, no, no, I think they did some damage to Sony. But that wasn't this one. Yeah, that wasn't this one. No, no, no.

I know that. But where I was going with that, though, is that back to the passwords that has been coming out about this that has been kind of interesting is seeing the common passwords that people are using, right? I think, like, on Twitter or Security Now, they've mentioned monkey as being, like, one the most popular Passwords that people have used over the years But I mean that stuff's being found out now Because of these hacks that are happening Because The data was just stored to where it could be Easily

Retrieved And particularly with the Adobe hack I remember hearing that A lot of people were looking at the Security questions and answers And so Yeah I remember hearing that a lot of people were looking at the security questions and answers. Rhymes with the S word. And one hint might be starts with P. The next one might be rhymes with the S word.

And if you put enough of these hints together, you can figure out what that security question answer was. And this is where the salting goes with the with the um you know exposing that sensitive data because if if yours if your password hint is rhymes with ass word and i see that your hash matches alan's hash yeah you got them both maybe alan has a really good hint given to his it doesn't matter because I know what his is. So, I mean, if it's salted correctly, then I shouldn't – You can't put two and two together. I shouldn't be able to see those together. Yeah, so that's a big one.

That's always going to be a very big one is trying to make sure you secure your data properly. Yeah, and this is another one that's hard for tools to find automatically. Yeah. So moving on to number five, and this one's a pretty big one. This one's security misconfiguration. And, you know, this one's unfortunate because it's so easy to gloss over when you're installing software and doing everything else. I mean, it takes a lot of work to secure things properly, right?

I mean, quite a bit of work. Security guys get paid big money. They really do, yeah. Right. I mean, uh, quite a bit of work. Security guys get paid big money. They really do. Yeah. So, I mean, this is a big one. I mean,

if you don't lock down privileges on your software, your hardware, uh, it's very exploitable. Yeah. And a lot of times, um, secure software is insecure by default.

You know, like, uh, the, um, like routers and stuff that you might buy at Best Buy or whatever for a long time there in the early days of Wi-Fi

they would have they would all use the default address 192 you know. Admin, admin. Admin, admin. They all have even the same name. It'd be like Netgear router. So you could get a pretty good idea of what that password's

going to be well i mean we talked about at the beginning where microsoft literally wrote the book on this stuff right and that's because they got hammered so much i mean like the first version of uh xp like it was wide open for everything it wasn't until like one of the later security packs where it actually had uh you know firewall and ports turned off by default right and you know i mean in fairness microsoft got hammered because they were the big boys on the block but that's also why they know about a lot of this stuff that's also why when we all install windows 7 and windows 8 you know every time you went to install a piece of software it prompts you with five million prompts are you sure you want to do this are you really sure you

want to do this come on are you i don't know that you really want to do this so one example i like to give as a couple years ago i was working somewhere that happened to reuse the same password in a lot of different places and somehow someone got into one server and then they were just able to use the same password they got in used to get into that server and to get into pretty much everything else okay but i mean like so in this security misconfiguration, there's a couple good examples that come to mind, though, from a.NET perspective.

So we kind of hinted on a moment ago with the verbose error pages, right? So every.NET developer, you've seen the, you know, the yellow screen messages, you know, server application error, and then some long exception message, but then at the bottom it will have the version of IIS that you're running

and.NET that you're running. That would be an example of one that you would not want to expose to external clients, which is good that you have the ability to turn that off for remote. But another example that came to mind too, as you were mentioning the passwords that were being reused, is leaving the passwords not encrypted in your web config files. Oh, absolutely.

I mean, there are other things mentioned. When you set up a server. There's a ton of things turned on by default that you don't use. If you don't use them, they should be turned off. Your application directory listing, like in Apache, a lot of times would be turned on. You can see all the files in there. Turn that stuff off. You don't want people to see that.

It usually boils down to and again that's why i said this one's so so frustrating is you have to know kind of what you're looking for to turn off in most cases i mean you install your server and all the software to go with it if you're not aware of every little thing you need to turn off you really should find out from somebody or do some searching. I'll give you the most basic one that I can think of, right? Ping. Oh, absolutely. Why?

From a default server perspective, in my opinion, why do you want to let somebody know that you're there for that kind of address? For a DDoS attack. Just let them know. just don't even reply yeah right I mean maybe I'm taking it a bit too far and it's certainly outside of their realm of dotnet but yeah so in the the concept of default little things being on that you don't really think about

right unless you actually sit down you know you're like oh yeah I don't actually need ping turned on yeah and one example i like is you don't see this so much anymore but application servers are applications sometimes that come with sample applications built in again if you uh install iis on like a windows 7 box or something it creates a default website for you and so if that default website uh that which you may have forgotten about, has some sort of vulnerability then you have a vulnerability too. That kind of thing doesn't happen too much anymore. I do all my shopping at

Northwind. Oh, and the one last thing is, and they hit on it pretty big here, is again, going back to patches. Make sure all your software is up to date. If you haven't patched your server in six months, well, you know, make sure all your software is up to date. If you haven't patched your server in six months, well, it's on you.

Make sure you keep all your code libraries up to date. If you're working on old libraries, well, you're at the mercy of whatever's going to happen there. Try and keep your stuff up to date. All right. So with that, we'll move on to number four, insecure direct object references. Insecure direct object references. Yeah. Yeah. It's so clear, right?

For a thousand. Yeah. So, no, this one's actually kind of cool. This is, if I remember right, it wasn't this city bank uh the the guy yeah this was this was the city bank hack yeah uh where they let go like 200 000 accounts or something it was it was it's really interesting so essentially what this one boils down to i guess you guys you kind of want to know what it is um when you look up in a url and you see user id equal 25 is a number typically when you see that you usually know that in the database that's probably a sequential auto increment field and so what happened is these somebody actually logged in to a Citibank account, had seen the user account information or the account number up at the top.

And they were like, huh, let me go ahead and change that account number and see if I can see what the next information is. And so they just kept adding, you know, adding one to it. And essentially they were able to gain access so through lack of authorization controls basically this person should only been able to see their own account through lack of authorization and through a little bit of just you know peeping around they were able to access over 200,000 accounts and grab that information So essentially this insecure direct object references focuses on authorization, but then they say you can also take it a step further. And instead of showing account number 12345 in the URL,

behind the scenes you might have a session table that maps 12345 to a GUID or something that you then show in the URL. And then when something gets passed back, it'll look that information back up in the session that you have and then try and map it back to the real entity. So it's kind of interesting, though, because this one really, it seems very similar to the missing function level access control, right? I mean, it actually walks the, it's like a border between that

and just shy of a SQL injection, right? Absolutely. Because you're not really doing – when I think SQL injection or just injection in general, that's more malicious. But this one, you're actually just – you're just changing the value of a parameter and that parameter then isn't being, uh, checked to see it. That's something that you have access to,

but yet letting you get back to it. So it's kind of weird that it, it, it's not merged in with the, well, again, it's this level. It's the name of it.

So what they're saying is insecure, direct object references. And just to be clear, um, from all the reading and listening I did on did on this particular topic, they said in most cases, it's not necessary to do the insecure direct object reference, meaning that you don't need to necessarily create something to obfuscate the real ID. If you're a bank, absolutely. You don't want to be showing the account numbers in the URLs or in any hidden fields or anything like that. So in those cases, they said, if you are a bank,

then yes, behind the scenes, you should probably be creating like a dictionary that says, okay, account number one, two, three, four, five is going to now be this GUID in the browser, right? So that nobody can reverse engineer that stuff because it's a throwaway it's a one-time key right um so i think that's why this one is specifically set aside for that because in cases where you do need that this can be extremely important but if you're just a regular website that's you know you don't have anything crucial to hide from anybody you're not you're not exposing personal information or anything like that do you need to go through all the trouble because this is actually a decent amount of programming right i mean if you're going if

you're going to be rolling your own session tables behind the scenes to map to something that's kind of fake on the site well but i think the point though is so like uh if you're gonna have parameters say in the url that that are exposed um only good for that session though yeah they should only be for that user don't don't don't yeah because because that's that's the whole point is not allowing the user to just be able to change that value to get to Joe's account data. Right. And you change the order number and the URL, and now you're seeing someone else's confirmation. You want to verify that order is associated with the logged in user.

Right. So you can either handle it through authorization, which is what they say. For most people, it's probably fine. Or the session indirection. Yeah. But if you are a bank or you are somebody handling like i don't know like yeah social security numbers and stuff then you probably should start looking into that um indirect object references all right so we're going to make our way into the top three

do you want to guess what number three is? Well, I could cheat. Yeah. Do we want to wait for our listener to call in? Right. I'm waiting. Still waiting. Yeah. All right, number three is cross-site scripting, the infamous XSS.

I've never heard of that one. Yeah. Right. Yeah, this one's really easy to kind of accidentally slip in to a site and not realize. And what's really bad about this is it's really easy for automated tools to find these. And the consequences are dire. So I've actually seen a demo where someone was able to find a small cross-site scripting vulnerability and they used it to inject a JavaScript file which then pulled a remote server for instructions on what to do with that person's session and so they were able to you know wreak all

sorts of havoc and add stuff to car and you know pop up redirect the person to their own URL and just everything the cat was out of the bag yeah what's interesting to me is is when you hear the term cross-site scripting you automatically think external right because that's what it sounds like but when you read the documents that the OWASP has prepared um that's not always necessarily the case it's just it's putting stuff on your page that does malicious things, right? Yeah, and it's, you know, the common way to think about it is usually form fields and URL fields. But there's also a variant called stored cross-site scripting attacks where, you know, maybe I put my name in some other website as alert something or other in JavaScript.

And then later when someone in the admin piece is going through and looking at customer records all of a sudden my name gets you know executed as javascript uh which is no way no so i mean just to be clear like what we're talking about here is like if you have something you have a form field you allow the user to enter some data and then that data is going to be displayed later in a page. So I think XSS is specific to code executing. So you put some JavaScript in the field. It doesn't actually have to be JavaScript.

You could inject some Ruby into a Ruby app or something as well, and that code actually gets executed later. So the big example here was the MySpace hack that happened, and that's what it was. It was, you know, the guy had, like, this gigantic, you know, JavaScript that he was able to put into a form field, and it later was actually a worm that propagated throughout the MySpace community that, you know, all of a sudden he was more popular than Tom.

Yeah, that is right. The good news is this is an easy thing to fix. All you have to do is properly encode the data that you show on the website. And you should do this not for just URL and form fields, as we said, but also pretty much for everything. So, you know, if someone can get something into a database and when you display that data for the database, you need to be probably encoding it for HTTP or HTML or whatever format you're showing. Yeah, that's a great point, too, because there's different encodings for JavaScript, for HTTP, for XML, CSS, all of it. Yeah.

Yeah. So you have to be really specific about where you're gonna how you're gonna put that into the code and i think one thing to note here seeing as how we do talk about dot net a lot that was interesting is that out of the box mvc is way more secure than web forms out of the box and the reason is because web forms doesn't do everything consistently it'll encode some attributes of a control but not others so the tooltip might not be encoded while the other stuff is encoded so there's a i think i think an example that uh that was discussed that troy discussed in one of his presentations was label versus button is that that what it was? Yeah, I think it was the, you know, if you took the value from a form field

and just stuck it in, I think button was encoded, but label was not, if I recall correctly. It was the same piece of data, and that's in web forms. And so you have to be a little bit more diligent if you are using web forms in trying to ensure that you are encoding all the data properly. Whereas in MVC, pretty much they said out of the box, like everything encodes everything. So you're already a bit further in the safety of that. So according to OWASP, though, cross-site scripting is the most prevalent web application security flaw.

It's number three on the list here, but it's the most prevalent security flaw. And it makes perfect sense. I mean, it takes a lot of work to lock these things down, right? Because another thing that has been mentioned that I find interesting is it's not that you just have to worry about, about things coming into your page. It might be things from your database that you're displaying on your page.

Well, you got in there. Example that Joe gave, right? Yeah. So yeah. And speaking of that, we mentioned sanitizing output,

but you also want to sanitize that on the way in. So you can prevent those store attacks on other people who may not have sanitized their output. Yep. Yeah. And I also wanted to mention that a lot of people will sometimes they'll try to do some sort of blacklisting to try and prevent this thing. It'll look for script tags or they'll look for single quotes in the URL, but you can get away with all sorts of stuff by like URL encoding the values or, or all sorts of different tricks that end up kind of putting that information back

together in a very bad way. So really, you html encoding that stuff is the way to go yeah web apps and uh another thing speaking of that with the url encoding all that uh one of the things that troy did bring up in his presentation that i thought was awesome uh is the way a lot of hackers are getting away with stuff like this, is they use URL shorteners so that you can't actually see what's in it. So if you're on Twitter and you see this link from a tiny URL or from a Twit or what is it now? I can't even remember. Yeah, Bitly and then Twit.co or whatever it is.

You're not actually going to see what you're about to go to. So when you click it, you could get something in the URL that's bad. And so it's pretty interesting. And it could be taking you to a perfectly legit site, but that site has vulnerabilities that are then exposed through the URL itself. So there are a lot of ways that this can be hijacked and and uh that's why it's probably number three on the list here yep yeah so moving on to number two broken authentication and session management yeah so that's just what it says all right yeah the example that owasp gave was you know having the session id in the url and then i let's say let's say i buy some concert tickets

uh there's a a tm company that sells some tickets that we all know and love because their prices are so awesome oh yeah and so uh you know and i'm like hey joe i got the tickets and i want to send you a link showing you you know the confirmation or something but i'm not meaning for you to be like actually get in my account but oh accidentally maybe i just gave you uh you know if the session was in the url then maybe you could go in and then continue on as me in order whatever you wanted to right and that server can't distinguish between us so i am you as far as they're concerned yeah and the interesting thing is is that would be fairly harmless if you sent it to joe

the problem is now today with social media more than likely you're going to tweet that out be like check out the tickets i just bought yeah and for and me and just well i mean not that this one was bad but i mean you bring up that example and it was just uh last night that i saw a tweet from tony hawk who had posted up the um mini cooper had the their configurator where you could save you build your car and configure it and save it and he had tweeted hey here's the new Mini I'm getting. So, yeah, I mean, if it, yeah, could you imagine? I hope he didn't have his credit card saved.

Someone's getting a couple Minis. You know, that's the kind of example where you're like, oh, yeah, let me get one too. Yeah. Let me go ahead and change the address in this account real quick. Hey, wasn't there a fairly popular company who also had a problem with this particular issue yeah the big the big one here was uh apple when uh i think it was when they released mountain lion it was the first version of iMessages that came out for os10 i believe that was in mountain lion and uh the hack was that uh as you were configuring iMessage,

if people on the same network with you could hijack your Apple ID account and gain access into everything that's iTunes for you or whatever you're using that account for. And also another example is sometimes with timeouts that are set too long, like someone's at a public computer, they just close the window, and you've got that session ID in a cookie

or something, and the next person that comes along pops open whatever website, Facebook, and now they're logged in as you. Yeah, and speaking of whatever website, Facebook, and now they're logged in as you. Yeah, and speaking of the public computer route, one of the things I said too is, as a developer, we need to be conscious of that stuff and try to leverage cookies. And the main reason behind that is, is if you're passing that session ID through your URL, that's all fine and dandy, but let's say that you are on a public computer. The next person who comes up can open the history.

And assuming that that session wasn't squashed properly, they can just look at the URL history that was there, click on it, and then they're in your account. So if possible, try to utilize cookie management for handling your session going back and forth between the server if somebody has cookies disabled okay well then maybe they just don't need to be on your site you know i don't i don't know the answer it's it's up to you what you want to do with that but you know something to be aware of generally speaking exposing things in the url is never a great idea right yep and another attack i really like here is like uh let's say um you know you've got someone michael comes over to my house and wants to use my computer to check his bank bank statement i'm like oh sure what's your bank and i type in the

the bank for him go to bank of america.com then i you know look at the cookies write down the session id then hand them the computer. Here, here you go, log in. And then he logs in, and then if Bank of America hasn't changed that session ID once he's logged in, then I can run over to another computer, set my cookie to that value,

and now we're both muggle outlaw. That's evil. Yep. I didn't know there was two of me. Yeah, not that I would do that to you. All right. So do we do a drum roll for number one? Can anyone guess?

Yeah. What haven't we mentioned? I don't know. We've gone over so much. What's a big one that... Hmm. And if you haven't heard of this as a developer, then you probably really need to listen

right now injection um sql injection uh injection and just injection yes injection because sql injection is probably the most popular right because isn't an interview 101 you know how do you protect your queries right so um that's probably the most prevalent one out there. And, you know, how do you protect your database? But it's important to note, though, we're not talking about SQL, just SQL injection. Right. LDAP, XPath, it's not just SQL. It's any kind of query if you're querying something regardless whatever service it

is you need to make sure that that thing is locked down to only allow proper things authorized queries uh validated inputs whatever it is um one thing i think is fun too is actually log injection so if you know what someone's logging framework, whatever, whatever those lines look like, and you're able to insert new lines, you could actually start inserting logs for them to make look like things that didn't happen did happen. It's kind of interesting. Oh, interesting.

So if you're actually taking over a system or something. Yeah. Yeah. Yeah. So what are some of the ways that you can actually protect your database? Whitelisting. No, that's not true. So databases, you know, you've got a primarized queries. You've got store procedures that require the inputs to be matched. What else? ORMs. ORMs.

ORMs. Good ORMs. They will automatically do the parameterizing for you. But just to be clear, stored procs don't necessarily save you from SQL injection. And there are several ways that it can be done. But in the olden days, if you had a query that had to be somewhat dynamic in the order buys or whatever it was trying to output the way that that people would typically do that is they would set a sql

query to a string value and then they would exec that string that that sql query so if in sql server for instance if you just do an exec and you're passing in values and it's just basically plugging it into the string, you get no protection. If there was an injection, if somebody put something malicious in there, they're still going to have access to it. So if you are doing something like a dynamic query in a stored proc, you need to use something like SP execute SQL and actually use the parameterized version of the exec at the bottom. So there are still ways. and actually use the parameterized version of the exec at the bottom. So there are still ways. It's not foolproof. Just because it's in a stored product doesn't mean that it's safe.

It just generally means that it usually is. Well, it just, yeah. So as a good practice, though, so there's some good practices that you can have there too, right? And for my personal preference, though, I like the use of stored procedures just to kind of break away that database layer from my application layer. Have that logic in its own container, so to speak. Yep. And encoding is big here too for stuff like XML or other types of injection.

You want to make sure that you're properly encoding for that format. Yeah. And this is also Joe mentioned and kind of retracted a second ago, but absolutely true. Whitelisting. If, if there are only certain values that, you know, should go into something and a whitelist doesn't mean it has to be a value.

It can be a type. If you know that a parameter has to be of type integer, then why are you going to let a string value in? So, you know that a parameter has to be of type uh integer then why are you going to let a string value in so you know there there are ways that you can actually protect before it ever even gets to your query level yeah that's kind of a recurring theme with this top 10 is a validation and encoding so the big one here the big example here we've kind of already hinted on would be the Sony attack. They got hammered. What was it like for at least a solid year?

It seemed like every month there was a new attack from them. Yeah, it was a bad year for them. Yeah, and the PlayStation 4 comes out tonight. And also, I think anytime we talk about sequel injection, we've got to mention Dear Bobby Tables, a famous XKCD comic that shook the world. This hypothetical parent has named her child Bobby, and the last name is single quote, semicolon, drop tables.

I don't know about the middle name, but yeah. So the school calls this parent up and is a little upset with what just happened to their database. Yeah. And by the way, chances are somebody is not going to do a drop table on you unless they're just really mad at you. Usually what they're going to be doing is trying to mine the data out of your database. And, you know, that's the dangerous part

yeah you're lucky if it's just the drop yeah if it's just a drop then you know hopefully you have a backup somewhere uh the worst case scenario they're going to walk off with your data and expose you know tons of usernames personal information much like sony, so let's see some predictions here. Like we're, we're, we're coming up on 2014. Who, who wants,

what do we want to do? A top one, top two. What do you think going into 2014? So, uh, I've got a prediction here this year, 2013,

Edward Snowden made a name for himself by, uh, who's that guy? Yeah. So I'm releasing some documents. What's his Twitter handle? I don't know. Why would I know that?

But he made a name for himself by releasing some documents from the NSA showing that there's a whole lot more spying going on. Well, I guess the tinfoil hat's new all along, but there's a whole lot of spying going on um then well i guess the tinfoil hat's new all along but um there's a whole lot of spying going on and so i expect that a lot more people are going to be looking at encryption for their companies and organizations and i i expect a lot of them are going to do it wrong so i'm guessing the number one or at least moving into top three is uh security misconfiguration. Hmm. Interesting. Yeah. Uh, mine is actually going to be, I think the cross site scripting is become more of a big problem because of

smartphones. That's what I think that, that people on their phones feel safe for some reason. And I don't think they take the same precautions they do with windows because that people on their phones feel safe for some reason. And I don't think they take the same precautions they do with Windows because Microsoft has always been bad, whatever. So I have a feeling there's going to be exploits that somehow allow lower-level access to systems on phones that are really going to cause some problems.

Because, I mean, people keep their lives on their phones. And that's where I think attacks are going to go. I actually thought Joe was maybe going to take mine as he was going down that route because I was thinking that sensitive data exposure would move for a similar reason. So, yeah, I don't know. Well, it's closer to one, so up, I guess. Yeah. Or, you know, unless you're looking at it numerically,

I guess it would be maybe down. You're talking about the highest priority. Yeah, I was thinking that sensitive data exposure might move in position, you position, like I said, based on similar reasons that you gave. Yeah. When you were saying it, I was like, dang, he's about to take mine. We should discuss these. Maybe we should be passing this company information around and playing tech.

Yeah, interesting. Well, I mean, Google's been making strides. I mean, they have been vocally, quite vocally pissed off about, you know, finding out just how their own government has been kind of taking advantage of their offering. So they've been doing a lot to encrypt everything end-to-end and SSL everywhere. Just in case you have been living on a rock and you're not familiar with some of the stuff we've been talking to,

I highly recommend checking out a podcast called Security Now, where they talk a lot about the stuff that's going on or actually made quite a name for themselves by predicting a lot of things that were later revealed about Prism and Snowden and NSA and a lot of the other stuff. Great stuff in that podcast. Steve Gibson is like my hero. That kind of takes us into our next section. We want to talk about some application security tools and resources like SecurityNow. Also, there's some pretty cool tools we discovered.

I can't say this. Havage. Havage. It was a security injection test tool. So it's got two versions, a paid and a free version. But, yeah, I mean, it looked pretty cool. I don't know. I haven't done any sql injection

uh you know testing on my own but when i found out about this tool i was like well that's actually kind of neat i kind of want to play with it yeah i mean if nothing else use it against your own site right not in production yeah yeah not in production right yeah no but i mean that's the whole thing like a lot of these tools can be used for harm, but they can also be used to help you solidify your own site. Well, yeah, so to that point, though, you've got to believe that it's out there. So any hacker that wanted to, they're going to be using it too. Yep.

Yep. And if you are going to be kind of hacking away on your own dev site um you might want to be careful with what fields you uh delete or you know mess with because someone else might be working on them at the time as well be a little confused about their data being manipulated sorry michael i don't know what you're talking about some other tools um backtrack linux is a distribution um it's pretty much made specifically for security testing and looking for exploits, metasploits. Another tool, it's really great. It really bundles up these exploits and makes them really easy to exploit.

So you can kind of double-click. It'll run through a bunch of stuff and then give you shell access, something like that. So you don't even know what's going on underneath. You just kind of right-clicked on it, or sorry, typed in the computer name, and there you go. Burp is kind of a cool tool. Burp Suite, it's a Java application that's good for really all sorts of stuff. It can act as a man in the middle. It can repeat requests.

It can act as a fuzzer to try and kind of fill in data and look for exploits on your site and also something like fiddler is a great lightweight tool for just kind of seeing the communication that goes back and forth between your client and your website yeah yeah it's not only interesting for that it's also uh because you got to believe that that if somebody wanted to attack your site they're going to use a tool like that to see what's being sent back and forth too so you might as well be on the uh on the edge of that too using it to see what you're actually sending back and forth to make sure you're not sending it back something you didn't mean to yeah that's why i have all these tools right yeah that's the cross-site request forgery

fiddler makes it stupid easy to do that kind of thing so yeah um but again it's usually it's supposed to be for development purposes so you know and there's a whole book written specifically about metasploit there's actually a pretty cool book i just remember now called um i think it's called gray hat uh hacking with python um it's it's cool. It actually will have you go through and build things like debuggers and fuzzers, and it gives you a nice overview or a nice kind of understanding of what these tools are and what they're used for. And speaking of books, there's actually a lot of really good books, and specifically audio books,

because I know you guys are probably audio fans if you're listening to this show. But Audible has a lot of really good books from Bruce Schneier, also Kevin Mitnick, who's famous for writing The Art of Deception, another book called America the Vulnerable. And you can listen to these books, and pretty cool. Awesome. All right, so with that, let's get into the tip of the week, or tips of the week. Yep.

And I wanted to mention a website called Cloud Cracker, which is a suite of tools specifically for cracking secrets and passwords. And so you can go to this website, give me your credit card number, and upload some information and then they'll give you like you know i don't know the prices offhand but

it'd be like uh they'll crack a wpa2 password for five bucks or they'll crack uh rsa password for 150 or whatever and they'll even show you like times. You just kind of get an email saying, here's your password. You're welcome. I had two that I wanted to... They're both kind of small. I thought

they would both be of value. These are within Visual Studio. Everybody knows about breakpoints, right? When you're debugging something. I think Alan had a couple episodes back. He had mentioned a tip about using named breakpoints. So one thing you can do while you're debugging your code is you've already gotten at your breakpoint

or past your breakpoint, and you're kind of just stepping a few lines through it. And later on, there might be like, you know, a for loop that you want to skip and you can go to a line past that and control left 10 and it'll just automatically execute all the way to where your cursor is currently at. But another cool thing that you can do with that is let's say that you're not in a debug session, right? And you want to test something and you don't really care to set a breakpoint, but you're like, you know what? I just want to run the application to where my cursor is right now.

Boom, control F10 and it'll start a debug session. And while you haven't added a breakpoint, it'll run it to where your cursor is and then stop for you right there. Oh, nice. So it's kind of like an ad hoc breakpoint that can happen for you. And so that's the first one that I wanted to mention. But then the second one is that if you do actually want to set breakpoint, one thing that's very convenient is if after you've set your breakpoint, you can right click on it and add a condition to it to say, you know, only stop when this that when this statement is true. And then that way, you know, if you're running through a list of like 10,000 names or something like that, you know, whatever it might be, you're only going to get to it in those circumstances that you

actually want to stop and see what's happening. Yeah, I thought I'd mention too, I've noticed a lot of people don't realize this, is you can actually drag that little yellow debugging arrow up in a lot of cases. There's some situations where it doesn't work, but if you ever kind of F10 past the thing you wanted to see, and you're like, oh no, you can actually just click on that arrow and drag it up a few lines and replay it. I did not know that. It's a little wonky

sometimes because values may already be set, but sometimes it's pretty useful. Alright, well I guess my particular tip of the week is something that just kind of came up tonight and please don't use this

on our site you know if you're gonna use it use it but it's a it's a it's a website called mailinator.com and like if you're ever looking up information or you just want access to that one thing on the site and you don't want to get spammed with emails and all kinds of stuff um you don't want to put in your user or you don't want to get spammed with emails and all kinds of stuff um you don't want to put in your user or you don't want to put in your own email because you're just like god i really don't want to sign up for more spam you can go to mailinator.com and you can literally create any kind of mailbox you want because it's public everybody in the world will be able to see it it doesn't matter but what it allows you to do is put in an email address we'll call it alan at mailinator.com you plug that into the site that you're you're trying to get some

information from you can actually go over to mailinator retrieve the email which by the way will be blown away in 30 minutes an hour something like that but then you'll be able to go click the link you know confirm that you have a real email address, and then go in and, you know, get the information you want. So, again, I'm doing this out of the kindness of my heart to save you from a ton of spam. We won't spam you. Please, if you're going to sign up for our newsletter, just go ahead and do it. I think this might be only for the parents out there, but is it just me, or does this sound like one of the natures made by Dr. Heinz Doofenshmirtz? For all the Phineas and Ferb fans out there.

Man. Nice. But I can tell you right now, like, this tool is invaluable if you need it. So, again, you should not need it for coding blocks because we will send you nothing but quality good content, right? I'm just expecting, like, Perry the Platypus to come busting in about this innater. Oh, before we close up, I do want to say, recently we've put some posts up about some JavaScript frameworks and things like that. If there's anything that you guys would specifically want to know about

or want us to spend some time talking about, please let us know. Contact us. Are you interested in, I don't know, whatever. Just let us know. Angular. Yes, Angular. Please know.

I mean, maybe. I don't know. I don't hate Angular. No, I don't know i know i don't hate angular all right so uh so with that we'll be putting up the links and the show notes and uh everything up on the site yes and uh go ahead and subscribe to us on iTunes, Stitcher, and whatever your favorite podcasting app is. And be sure to leave us some reviews on iTunes and Stitcher that will help us jump up in the ranks and give us some motivation to come to you a little bit more often even. And visit us on CodingBlocks.net where you can find our show notes, examples, discussion, and more.

And send your feedbacks, questions, rants, comments, and everything else to comments at codingblocks.net. Thank you.