OWASP Top Ten: Go Code Review
Key Points
- Open‑source software is free and community‑supported, but developers must take responsibility for its security by reviewing and understanding their code.
- The session uses three simple Go code examples to illustrate common OWASP Top 10 risk categories, letting participants engage by spotting symbols that indicate questions, thinking, and answers.
- In the first example, the key security flaws involve displaying passwords in clear text, logging them, and storing them without hashing, which constitute cryptographic failures.
- Proper mitigation includes never showing or logging raw passwords, hashing (with salting) before storage, enforcing password‑complexity rules, and sanitizing inputs to prevent SQL‑injection attacks.
- The discussion reinforces that secure password handling—hash‑and‑salt, validation, and safe database interaction—is a fundamental part of open‑source security hygiene.
Sections
- Untitled Section
- Securing Passwords and File Permissions - The speaker outlines best practices for encrypting passwords in databases to guard against admin and log exposure, then explains Unix file permission bits (like 0700) and how they control owner, group, and others’ access.
- Avoid Sleep Loops, Use Daemon - The speakers warn that busy‑wait sleep loops waste resources and lose state, recommending a background daemon for notifications while also emphasizing the need to re‑check user authority before sending alerts.
- Importance of Data Validation - The speaker stresses that proper data validation prevents critical issues such as out‑of‑bounds memory errors and SQL injection, then closes a quiz segment and encourages viewers to comment, like, and subscribe.
Full Transcript
# OWASP Top Ten: Go Code Review **Source:** [https://www.youtube.com/watch?v=0tl_0nP6Eyg](https://www.youtube.com/watch?v=0tl_0nP6Eyg) **Duration:** 00:11:29 ## Summary - Open‑source software is free and community‑supported, but developers must take responsibility for its security by reviewing and understanding their code. - The session uses three simple Go code examples to illustrate common OWASP Top 10 risk categories, letting participants engage by spotting symbols that indicate questions, thinking, and answers. - In the first example, the key security flaws involve displaying passwords in clear text, logging them, and storing them without hashing, which constitute cryptographic failures. - Proper mitigation includes never showing or logging raw passwords, hashing (with salting) before storage, enforcing password‑complexity rules, and sanitizing inputs to prevent SQL‑injection attacks. - The discussion reinforces that secure password handling—hash‑and‑salt, validation, and safe database interaction—is a fundamental part of open‑source security hygiene. ## Sections - [00:00:00](https://www.youtube.com/watch?v=0tl_0nP6Eyg&t=0s) **Untitled Section** - - [00:03:13](https://www.youtube.com/watch?v=0tl_0nP6Eyg&t=193s) **Securing Passwords and File Permissions** - The speaker outlines best practices for encrypting passwords in databases to guard against admin and log exposure, then explains Unix file permission bits (like 0700) and how they control owner, group, and others’ access. - [00:06:56](https://www.youtube.com/watch?v=0tl_0nP6Eyg&t=416s) **Avoid Sleep Loops, Use Daemon** - The speakers warn that busy‑wait sleep loops waste resources and lose state, recommending a background daemon for notifications while also emphasizing the need to re‑check user authority before sending alerts. - [00:10:48](https://www.youtube.com/watch?v=0tl_0nP6Eyg&t=648s) **Importance of Data Validation** - The speaker stresses that proper data validation prevents critical issues such as out‑of‑bounds memory errors and SQL injection, then closes a quiz segment and encourages viewers to comment, like, and subscribe. ## Full Transcript
We all love open source software for a lot of good reasons. It doesn't cost anything. It has
community support, sometimes even industry support. But it comes with a responsibility.
One of those is making sure that it's secure. And one of the videos that Sahdev brought us was about
the three As of open source security. Part of that involved reviewing your code-- getting to know it. And so he's brought us to challenge!
That's true, Dan. So we will look at three examples of code. They're simple examples written in Golang, but easy to understand by any developer. The beauty
of the simple code is that they represent three areas of OWASP top ten security risk areas.
Cool! Okay, so let's take a look at our first example. And by the way, you get to play along too. Look
for this symbol when I ask the question. And then you'll see this symbol while I'm thinking
about it myself. And then finally, the answer will show up [with] this symbol. So take a look
at our first one-- is about someone getting a password. And there's this kind of the question
of security and code. So the first thing that jumps out to me is, is when you're doing a scan,
the password is going to be shown as the person is typing it. Now, I don't know if that was exactly
what you were after. So that's going to put down is my first one is is don't show the password.
Right? But that might not be what you were after. The other thing that kind of jumped out at me,
besides that, is when you say to save the password, and this is where I was doing some
security audits myself. And they mentioned that when you have critical data, you don't want it
ending up in logs, for example. And so here, I wouldn't be passing around a password that is in
the clear. In fact, a smart way of doing this is, is you run a hash on it first. Because you really
don't care about what the person's stored as their password. You care "will the hash of it actually
match?", which is good enough for password security purposes. The other upside is, is that
when you pass into the database, you can avoid a potential problem where someone has inserted
things in that password that's trying to do a SQL injection. And that's where someone is trying to
trick the program into running a SQL query that really wasn't intended. That's the three things
I think I was talking about -- was running a hash. Make sure... Oh! And also make sure that
the password has the keywords, er, the complexity that it should have. And also the SQL injection.
Those are my three answers. That is my final answer.
Well, you did good, Dan, I must say that. So, this is an example of one from OWASP top ten-- this is an example of cryptographical failure.
You never store passwords in plain text. Hashing with salting, that's what you want to do. [Dan] Right, exactly.
And then second thing, as you said, with complexity. One other thing is, it's not checking,
you know, at a minimum, the length of password. The longer the password, they tend to be more safer.
We have a bunch of videos on that topic, as a matter of fact. So be sure to check it out. Now,
one other thing to think about is when you look at your password and it's being stored in a database,
not just storing it in clear, at any time is both at-rest and in-motion. That's kind of what I use
as a rule of thumb. If you have sensitive data, you have to think about both cases. Can a DB
admin see it and can it be potentially exposed in the logs? So that's kind of question. [Sahdev] That's
you got it. [Dan] Great. Okay, now we're going on to the second one, which at least wasn't quite so easy.
So here we are. Now, okay, this requires just a teeny bit of explanation for Q2. And you see this permission here of 0700. For the
Unix-- people who are newer to UNIX, let me point out what that means-- that's referring to the
[file] permissions. It's a bit pattern where each one of these numbers represents the permissions for the
owner, group, and everyone. And so, for example, this says that-- it's a three bit pattern --that
they have execute, or traverse rights, read and write. That's essentially what the 7 means.
And I have to admit, when I first looked at this, I didn't really see a problem because it's saying essentially, this 700 is saying "I'm
going to let the owner be able to read, write or traverse it", which is perfectly the legit--
and no one else can. Another common pattern you'll see is 755 saying essentially the owner can do anything they like and the
other people can read or traverse. I had to look this one up, and if you haven't hit pause already,
here's your opportunity to go do that and look it up yourself. I tried to find some potential
flaws here. One thing it mentioned was the umask capability, where you have the masking that's
applied by the operating system to a newly created file. Though I don't know if that's
what you were after. The other possibility is, is that there's a coding question here
because you're checking to see if the error that came back was nil,
but it could have already existed. So that was really, one was umask, prior existing...
And the other one? I give up. Can I phone a friend? [Sahdev] Well, no, you pretty much got it, actually.
Really?
So the one big thing here is every time you use any function, here Go package mkDirAll. Or using third-party packages, right, you must understand the
function before blindly using it. How it works. So mkDirAll, it's a function that will create the
directory for you with the desired permission, if it's not there. [Dan] Yeah, if it already exists,
it'll just leave it alone. It doesn't even return an error. [Sahdev] Exactly. So what's missing here is "What
if there's a directory there with 0777?" [Dan] Yeah, right. In fact, when I was looking up through Stack Overflow,
there was this big argument about a potential race condition for this, too. Because as you check to
see, is that come back in an error, and then I checked to see it exists-- in between, potentially
someone could have come in and created that file. And so it turns out this is actually, for such a
small problem, it's really something to look at. [Sahdev] It's a small but this is one of the, like I said,
this is the top, actually, this is the number one problem in the top ten risk areas-- broken access
control. [Dan] Wow. Okay. So let's go out to the last one then. And so that's question three. Okay,
so I have to comment first that I'm not really happy with this as a code example because it
kind of offends from a few other ways besides security that I feel compelled to point out.
One-- please don't do this where you write a sleep loop. That's kind of a bad idea overall,
because that means that the process is going to continue to consume resources.
It also means the process has state in it, and if it is somehow terminated,
you've lost that state. A more proper way of doing this is is that you should create some sort of
background daemon that you register these sleep notifications-- I'm sorry --these notifications
with and hopefully that will do the result that you want. I don't think that's what you're after
though. [Sahdev] That's true! [Dan] Yeah, but I felt compelled to mention it! But I think what you're after is,
is that if you're doing this sleep notification, especially if it's just for a longer period,
potentially the access rights to the person you're notifying has changed in between the
time. Like imagine, for example, you're getting an email notification coming from one of your systems
and they need authority to be able to do that. Well, if I withdraw that authority and I have this
background process running, potentially I'm going to be notifying them, giving them information,
leaking them information that they really don't have a right to do. And so in this code example,
where they're in the-- coming out of this reminder --they should check to make sure that that user
has the [authority] to do that. [Sahdev] So, you do touch a couple of good points. But the one of
the main thing I'm looking here from security risk areas and which is number three in the OWASP top ten: input validation
or data validation. So what are we doing here is, we're getting the input, right? Let's say you got, 10 minutes.
Now, as you said, you know, using sleep here just for simplicity, right? Only in real
life, you know, in Golang, you may be using Go routines. Write a trigger running, right? A
daemon running, right? And that might be running for as long as the app is running and sending
reminders or some sort of... [Dan] You're saying, for example, someone passes in a 1000 minutes or something like that or repetitive,
that's very... [Sahdev] That's true. Or think about it. You want a notification every ten minutes, for example, or every one hour, right?
You make a little bit of logic change here. So, you know, one hour for 30 days, 24 hours, or every day for the whole month.
What if somebody passed a negative value? Or zero? We're not checking it! Instead of one hour or 10 minutes or whatever
you decide, it's going to send it instantly. Because it's zero or negative. So that will one,
it's going to be incorrect from what your expectation. Second is, we're logging it, right?
Depending on, like you said, the total numbers, because there's no cap here either. It can really
use all the hardware resources, the storage. Keep logging, logging and like instantly. And your
expectation was every hour or every few minutes or so. But because you didn't check the input, it
can crash your system. [Dan] That's a good point. And in fact, I would argue that if you're
looking at parameter checking, it's not a bad idea to even check it between routines. When you're
passing-- someone's passed you a parameter --at a minimum as an assert statement, to say "These
are what I expect as reasonable parameters." If you want to for performance reasons, you might
have them optional at runtime. But certainly during unit tests, certainly during integration
test and during your final testing, you want to have every single routine test to make sure that
a state is expecting is actually legit. And in this case, the one I got wrong, I didn't.
Yeah, this is the easy thing, but sometimes we miss it, right? So the data validation, when it's not done
properly, it can create severe problems-- out of bound memory. SQL injection is other thing where
because -- you can prevent it through the through the validation. [Dan] Well, great. That was a fun quiz.
Let's go ahead and wrap that up. And I'm curious down on the comments, I want to hear how many
did you get right and if you found anything else that I might have missed. So there it is. Thanks
again, Sahdev. [Sahdev] Thank you, Dan. In the comments also be sure and leave us what you'd like to see
in other Tech Talk topics. And before you leave, please don't forget to hit Like and Subscribe.