#168: 10 Python security holes and how to plug them Transcript

00:00 Michael Kennedy: Do you write Python software that uses a network, opens files, or even accepts user input? Of course you do! That's what almost all software does. But these actions can let bad actors exploit mistakes and oversights we've made in our code that will allow them to compromise our systems. Python is safer than some languages, but there are plenty of issues to be careful of. That's why Anthony Shaw and Anthony Langsworth are here to discuss Python security. This is Talk Python to Me, Episode 168, recorded June 28, 2018. Welcome to Talk Python to Me, a weekly podcast on Python: the language, the libraries, the ecosystem, and the personalities. This is your host, Michael Kennedy. Follow me on Twitter where I'm @MKennedy. Keep up with the show, and listen to past episodes at talkpython.fm, and follow the show on Twitter via @talkpython. Anthony Shaw, Anthony Langsworth, welcome to Talk Python.

01:05 Panelists: Hey Michael, it's great to be back. Hey Michael, I'm good to be my first time.

01:09 Michael Kennedy: Yeah, it's good to have you here. So we have a bit of a name conflict here, so Anthony Shaw's, Ant. And Anthony Langsworth, is Anthony for the rest of the show. Hopefully that works for you all out there listening. And we're going to cover something that, I think is often overlooked in Python. The whole security side of things, right? I mean, I feel like, well, there's no buffer overflow issues, and things like that. So we must be just totally fine, right?

01:34 Panelists: No. If only that was the case. If only that was the case.

01:39 Michael Kennedy: Exactly. There's actually a ton of interesting vulnerabilities, and things that are pretty common, I suspect. Still in some circumstances, that we're going to go through. But before we do, I'd like to hear you guys story, really quick. Anthony, how do you get in a programming of Python?

01:54 Panelists: I mainly got into programming Python through networking programming. One of my responsibilities here, is interacting with a lot of Cisco and Juniper hardware. And Python is what they use, so.

02:04 Michael Kennedy: Right on. And Ant, how 'about you? You've talked about getting started on Look Cloud last time, right?

02:09 Panelists: Yeah, that was me. I was in Seattle, and I got sick, and I was stuck in a hotel for the weekend, so I learned Python. And never looked back since then.

02:17 Michael Kennedy: Most people, most people say I got really sick, so I stayed in bed. Other people, like you, are like, oh I learned a new programming language 'cause I wasn't feeling well.

02:26 Panelists: And nowhere to go.

02:27 Michael Kennedy: It's awesome. I totally get it. Let's start first talking about just security in general. Like Anthony, how do you... How do you think we should start thinking about security, as software developers, and people that run servers, and stuff like that?

02:41 Panelists: What I tell people is, when they start thinking about security, they have to invert how they think. Developers are very good at thinking, how do I build something quickly, and best designed well, and that keeps my customers happy? Security is not like that. Security is, how do I break something? How do I compromise something? How do I bend the rules? So you almost need a tester style thinking. So you look at what you've built, and think well, how do I make it do things it's not meant to do?

03:12 Michael Kennedy: I find there's just so much creativity in that. It's really hard to think about. And unless you see some examples, of it in action, it's almost hard to conceptualize some of these things. Like I remember the first time I saw the actual code for a buffer overflow exploit. Here's how it overflowed the buffer. Here's how you get it to execute this bits, that you've dropped in on, and I'm just like that is just... That's a different way of thinking, let's say.

03:38 Panelists: Yeah, and I mean, let me say, some of the who do this, they're really smart, and they get really technical. But I also want to stress, that a lot of this stuff is not rocket science. A lot of this is looking at what you do, and just trying to... trying to keep that mindset.

03:53 Michael Kennedy: Yeah, I think that's a really good point. It's easy... It's easy to get overwhelmed, thinking you know, this stuff is super advanced, but actually, 99% of the time, it's like, did you change the password, from the default admin password, on the database? And stuff like that, right? That's where people usually start whacking on it, right?

04:10 Panelists: Exactly, exactly. If, I mean, most people make a big deal about these super, super complex hacks out there. But if you talk to people, like Kevin Mitnick, and so on, a lot of the stuff that we're doing is functional engineering, which is just simple, as you say, password stuff, or basic configurations. A lot of the times with security, if you get the basics right, the simple stuff right, the attackers will just go elsewhere. 'Cause they're looking for the easiest exploit.

04:35 Michael Kennedy: Yeah, there's just rattling the doors to see if it's open, right? Exactly. Yeah, and Ant, how 'about you? What are your thoughts on this sort of security thinking, versus developer thinking?

04:43 Panelists: Yeah, I mean, I guess probably the difference between Anthony and I, which is I guess confusing, because we have the same name. Although we sound quite different, hopefully that'll be more obvious to the viewer, if we have different accents, is that Anthony spends a lot of his time, I guess, looking at things from the security angle. Where as, most of my time, has been spent from a development angle. And I've been curious about security, I guess, for a long time. My first job was doing, sort of, systems support for servers, and dealing with hacked servers, and was a pretty common occurrence. And I guess learning how people got into the systems, what they did once they got there. And it was kind of showed in the movies, like there's, you know, this person in a dark room, with like a green screen, and it's all like super technical. And they've always got a hoodie on, and they're always playing some sort of like metal music in the background. But actually, when you are more familiar with I guess how systems get compromised, it's just people running scripts, that just pinging server, after server, after server, looking for known vulnerabilities. If people haven't configured stuff properly, or they've left values, and there's bad passwords, and they just poke a hole in it, and then have their fun, basically. I mean that takes up a lot of people's time, and a lot of the security challenges. So, my kind of curiosity has been, how can I write code, in a way that I'm not doing things, which this attackers are going to be excited about? Like, what mistakes could I be making in my code, that they're going to be like, aww fool, he left this particular vulnerability. He didn't read this obscure documentation page. And it does come across like that to people, like it seems hard, which is I guess why I put that article together, to point out some of the more obvious ones. But, um... And they're not that complicated.

06:28 Michael Kennedy: Yeah, that's a really good point. Most of it isn't that complicated., it's just knowing that what is out there. You know, me personally, I don't think about it the way that you do Anthony, in terms of like, how can I break things. I think of it more as like, a super paranoid forgetful person. Which I'm fairly forgetful, in general life, as it is, but not paranoid. But I'm always thinking like, oh my gosh, what have I forgotten? What is the thing, that is just wide open, that I forgot? Did I forget to turn on the firewall, that blocks the database support publicly? Did I forget to, you know, validate this one thing? I think, you know, a while ago, there was one admin page on my site, that didn't check whether this person was an admin, or not. And if you could come up with this random URL, you could've found it. And I'm like oh my gosh, I can't believe I forgot that. So that's sort of my feeling, is like a constant uneasiness, of I know there's thousands of people attacking this site constant... Not constantly, but throughout, you know, sort of continuously, I guess. And it's like well, when will they find the thing I forgot?

07:30 Panelists: It's an ego driven security, as it's called. But that's cool. That's cool. If it makes you more secure, then go for it, please.

07:37 Michael Kennedy: Yeah, I think it probably does. I mean, I'm always double checking stuff, and I think it does really really help, so. There's a lot of these things you can address, and I think it's probably time to go through this list. So when Brian and I spoke about this on Python Bytes, just yesterday, actually it came out today, but we recorded it yesterday. And he was like, well the ones that were obvious, they're not even here. I mean, some of 'em are, but some of 'em weren't, like I... Like Python... You know there's the eval, eval user input, like don't do that, right? So I think you have a really interesting list that you put together here. Some of which will be people like, oh yeah, I've heard of that. Others like, really, I didn't know that was a problem. And then they'll frantically pause the podcast, and they'll run away, go look at their systems. So you want to take us through the topics, and we can sort of spend a little time on each one? Yeah sure, so I guess I left out some really obvious ones. I mean, eval's probably the worst one. Like you wouldn't just accept input from the Internet, and pass it through eval, I hope. You say that, you say that, I'm sure it's happening all over the place. It's easier to sort that way, when you just pass the lambo on the command line.

08:46 Panelists: Yeah the PHP equivalent is the reason that you're getting all those entries in your logs, looking for wp-admin. Anyway. I so, I guess the number one is input injection, which is just common across languages, across frameworks. It's nothing specific to Python, but this is, you know, where someone is basically noticing that you're creating the SQL queries, and you're taking a parameter, and you're injecting it into it's string literal. And what they can do, is they can escape the quotes you put around the argument, or the filter, or whatever it was. And they can basically run arbitrary SQL queries on your table. So SQL injection I think is pretty well known. And it's pretty easy to avoid. There are libraries for doing sensible escaping. There are libraries for basically parameterizing your SQL queries, which is really the way it should be done. But time and time again, that's probably seen as one of the most common things in web applications.

09:43 Michael Kennedy: And it is one of those things that won't die, right? Like it's just, there's still popular blog posts that have examples of SQL injection attacks. All over... And people just read till they get it to work. They don't go to the comments and say, don't do this, don't do this.

09:56 Panelists: Yeah, 'cause it's like when you learned SQL, or if you learn how to create SQL queries, it doesn't... Like there are so many tutorials out there, that actually show you the wrong way to do it. So this is why it keeps happening. Yeah, this is why it keeps happening, 'cause people are like, this is how you write SQL query. And then, okay, you want to filter by a particular user, or a particular id, or whatever, here's how you write a where clause, and oh you, let's take that as a parameter.

10:20 Michael Kennedy: Yeah, yeah, 'cause it's simpler, right?

10:21 Panelists: People are learning the wrong way to do it everyday, and we're having to unteach them that kind of practice.

10:27 Michael Kennedy: Luckily, there's a cartoon to remind us.

10:30 Panelists: xkcd?

10:32 Michael Kennedy: Yeah, are you familiar with little Bobby Tables?

10:34 Panelists: Yeah, absolutely. And I've seen the picture, there's a photograph, as well of a car, where someone's put on their license plate, they've actually tried to put a SQL injection on their license plate.

10:44 Michael Kennedy: Get all those license plate readers, that was brilliant.

10:47 Panelists: Yeah, so the license plate readers would crash, that's the intention anyway. And then I guess the other version of that is command injection, where you have a script, which needs to call a local process on the machine, like an encoder, or a specific executable, or something like that. I mean, Python has a few ways of doing that in the standard library. There's subprocess, there's Popen, there's in the OS module, where there's another way, and there's many ways, that similar to SQL injection, you can take an argument from somewhere, and people can escape that argument, and use it to run arbitrary commands on the server. So that's command injection, or shell injection it's called.

11:28 Michael Kennedy: That sounds a little bit bad. And that one actually was surprising to me. I wasn't super familiar with that. But if you're going to do Popen, and pass a string, as the command to run, you could easily do dollar sign, dollar sign, next command, or semicolon, or whatever the separator your shell uses. 'Cause you can issue commands, that have multiple operations, one after another, in a single line, right?

11:49 Panelists: Yes, so the most common example is, somebody writing a... Basically calling an executable, and then giving it an argument. Let's say you want to create a thumbnail, or encode an MP4 or something, then you'd call a local process, which does the encoding. And you'd give it an argument, which is the name of the file you want to encode. So that's straight forward, except that, if instead of a file name, they close the quote, and then they do a semicolon, or an ampersand, ampersand, and then they can put in any other command they like.

12:17 Michael Kennedy: How could that be wrong?

12:19 Panelists: How could it go wrong? And it's funny, 'cause I shared this post, and I saw some of the discussion forums, people arguing back saying, oh no that's not a problem. Why, how could that possibly be a vulnerability? And even if you kind of like make it really obvious, people don't look at it like an attacker would look at it. They look at like, oh why, who would misuse that? How could that happen?

12:39 Michael Kennedy: Exactly, that's flexibility, it's good. It means good things. Yeah, and I think it's... I think it's really interesting to have these two contrasts, not just SQL injection.

12:45 Panelists: And I was going to add too, that there's in addition to, the escaping and stuff that Ant is talking about, there's additional things you can do here to protect yourself. So for example, if you can run as the least privileged account you can. So don't run as root or administrator, for example. So if you do happen to have a bug in your application, where someone can do command injection, you're going to minimize what it can do, so there's multiple levels of ways you can protect yourself here as well.

13:15 Michael Kennedy: I think that's a really good point for a lot of this stuff, right? It's sort of, security is layers, not the one big silver bullet, right?

13:23 Panelists: Yes, very much so. Yeah, the Python way around that is, well first of all, avoid doing this if possible, for... I mean there's many other ways of doing spawning processes, and doing them correctly. But if you have to, if you need to escape the input, then use the shlex module, which is built into standard library, and it has a utility function for escaping shell commands.

13:45 Michael Kennedy: Yeah, what I really like about your article, which I don't know if we said it explicitly, it's Ten Common Security Gotchas in Python, and How to Avoid Them. And we'll put that in the show notes, of course. And for many of these, you have these, oh did you know there's this other module you can just use that fixes this problem? So that's... It's really nice that you have, sort of, some way to deal with this, not just like, to put paranoia into people. This episode of Talk Python to Me, is brought to you by Test and Code, and the Python Bytes podcast. If you love podcasts and Python, and you're listening to mine so you must, right? Well don't miss out on these two other great podcasts. If you're in a hurry, and just want the headlines, get the rapid fire Python Bytes podcast, that I co-host with Brian Okken over at pythonbytes.fm. Brian also host's his own show, Test and Code, at testandcode.com, where he explores topics like test driven development, continuous integration, code coverage, and Pytest, of course. As well as, agile development, mentoring, public speaking, and lots more, in an opinionated mix of interviews, and solo episodes. Keep up with the latest news, and become a better developer, by listening to Python Bytes, and Test and Code.

14:54 Panelists: The next group of attacks are all related to deserializing, or serializing data. And this is a pretty common vector, where let's say, you're writing an application that reads, configuration from somewhere, and that can be in YAML, or JSON, or XML, or it's receiving a message from somewhere, or you're basically using it as a way of communicating between different processes. There's different ways you can do that in Python, you could use XML, or you could use JSON, you could use YAML, or you could use Pickle files. So all four of those have massive gaping holes in them, which you could drive a bus through. So I kind of explained, how you could've abuse each one of them. I guess, people might could assume that XML is the safest.

15:39 Michael Kennedy: Yeah, it seems sort of old school, but XML can get complicated on the edges, you know. Like weird name spaces, and referring back to itself, and other sorts of bizarre things that nobody ever does.

15:50 Panelists: Yeah. So the one I kind of explained was the billion, what's called the billion laughs sexploit.

15:58 Michael Kennedy: It's funny, and it's... You know, look if you're going to get like taken down, at least it should be a funny sort of hack, right? Come on. Got to appreciate it.

16:06 Panelists: So, this is if you wanted to, if you received an XML payload from somewhere, and an attacker has access to put their own XML in there, then basically, XML has this thing called Entity Expansion. I guess this most similar way to think of it is, a zip file. And what you could do... Imagine you created a text file, and it just contained spaces. Lots, and lots, and lots of spaces, like, let's say a million spaces. Now if you compress that into zip, it compresses down to nothing, 'cause the way compression algorithms work. But when you extract it...

16:41 Michael Kennedy: Think, well oh it's one character.

16:43 Panelists: Yeah, exactly. So it can condense down to pretty much nothing. And let's say you compress that into a zip file, and then you made ten of those, you copied it, and you pasted it ten times. And then you copied those ten zip files, and then added them to a zip file, and then did that again, and again, and again. Now what happens is if you extracted that zip file, it would go in, sort of recursively extract the zips. And it can go from what something like a one kilobyte zip file, to gigabytes, or potentially even worse. So the XML version, that's called a zip bomb. The XML version is a similar idea, where in XML you can have basically, you can sort of reference things. So entity expansion, it can kind of reference something, which references something. So it's similar to a zip bomb, where you kind of create this tree, and then it basically exponentially expands. So, when you're trying to deserialize this special message in XML, it can take up gigabytes of RAM. So that's basically the exploit, is that it takes your server offline.

17:44 Michael Kennedy: And, here it is fitting on one screen, with word wrapping.

17:48 Panelists: Yeah, and it's like eight lines of XML.

17:50 Michael Kennedy: Yeah, it sort of teaches you that exponential stuff, and like factorial type things. They get big fast.

17:55 Panelists: Yeah exactly. So that XML one's pretty bad. There's some other pretty well know ones with XML, so if you actually look at the standard library documentation for Python, and this is how I came across this, it does say in a big red box, that there are known security challenges with XML, and you shouldn't deserialize arbitrary XML documents.

18:15 Michael Kennedy: Unless you do like SOAP web services, then what could go wrong? Exactly, so I guess the alternative is you can use a package called Defused XML, which is a third party package. But it was actually written by Christian Hymes, who's one of the core developers in Python. He's a security expert of Red Hat, so he kind of put together, I guess a safer version, of the XML standard library module, and it's a drop-in replacement. That's awesome. Does it just like not support these self inferential things, and some of the other dangerous bits? It's like a limited XML?

18:46 Panelists: Stuff that it would be really unlikely you'd have to use anyway.

18:48 Michael Kennedy: Yeah, Anthony as a network person, like how do you think about these issues? Like do you scan for these sorts of things, or?

18:56 Panelists: They keep me up at night. Look, there's a whole class of exploits with XML. There's exploits where you can imbed schema information into there, and do weird stuff with schema. I generally think that, if you are going to handle XML, you generally white list what you accept. You define your own schema, and say, if it doesn't match that schema first, I'm not going to parse it, or I'm onlhy going to parse minimal pieces of it. You can use what's called, an XML external entity attack, where you reference to a schema, or an inclusion from somewhere else. And that somewhere else is relative to your server. So by getting you to upload a piece of XML, they can try to get your server to load something from your internal network, and potentially just flat back the attacker. So XML can be used as a reconnaissance tool as well. It's not to say that XML is bad, but you have to follow the advice that Ant is giving you now, to use it properly, and use it well.

19:52 Michael Kennedy: Yeah, stay away from the dangerous bits, unless you really need them, and it's rare these days, I think, that you need them. And it seems like, you know, early 2000's, XML was supposed to be the answer to all the questions that involved any form of connectivity, right? Like, we have all these fancy things with XML. We had all the hype around SOAP services. You have XSLT going wild, being like the way to generate all sorts of stuff. And I feel like we've kind of moved on, but there's still plenty of XML processing around.

20:23 Panelists: XML has its place. It's a great metadata standard, with a lot of bells and whistles attached. The problem is 90% of people don't need those bells and whistles, but it is what it is.

20:34 Michael Kennedy: Yeah, I guess I shouldn't knock XML, I mean, it is the main bit of traffic on some of my websites with the like the podcast's RSS feed. That thing gets hammered. So I guess I should love XML, but that's the simple version. So another thing Ant, that you put in here, that I thought was really interesting is, people relying on assert to actually do runtime control.

20:58 Panelists: This one is pretty obscure actually, and not that well known. And that is, that this, effectively, an optimizer, well there's a series of optimizations you can do in Python. And you can run Python in optimized mode, which does... I mean if you look at the history of Python, basically what it tries to do is, traverse the syntax tree, and kind of make assumptions about how it should be executed, so that if you're doing it in production, it almost removes commands out of your code, and skips them, or it looks at them differently. So there's this thing is like constant crushing constant together, loop unfolding, and there's a whole bunch of optimizations. One of those optimizations is to ignore assert statements. Because really they should be used for debugging. So if your use to any other programming languages, so sometimes you can basically create like a debug assembly, or a runtime assembly, where they have debug symbols in one, and it's designed for production in another. Python basically has that but it's by adding an extra flag when you execute the Python file. So it'll skips certain commands, depending on whether it's running in optimized mode or not. So if you use an assert statement, to do things like checking if the password is right, or checking that the user has the right amount of privileges, or whatever, then basically it all runs fine in unit tests, and integration tests 'cause you never use optimized mode, 'cause you was what the assert statements. And then when you actually deploy it, production, someone says, oh Python is quicker, like ten... you know, 10%, 20% quicker if we run it in optimized mode, they switch the flag on, and all of your security you know, catches, and everything like that, it just disappear.

22:39 Michael Kennedy: Yeah, I mean they could be totally, sort of silent as well, right? If you were doing like containers, you could depend upon a docker container, and the base image could change in a way, they're like, yeah we made it a little bit better. It's faster. Oh great, I love faster, let's do that. Great, why can't people be on this page again? This is terrible. Yeah, that's pretty scary. So the fix here is, don't do that. It's like doctor, it hurts when I raise my arm. Well, don't do that. Keep your arm down. Basically, like just use a if, you know, not admin raise exception PermissionError, or something like that, right?

23:10 Panelists: Yeah, typed exceptions.

23:12 Michael Kennedy: Yeah, exactly. Wait, this is how it's supposed to be done anyway, okay. And another one that's pretty interesting, it's not as common for the web, 'cause of the latency, but is pretty interesting, are timing attacks. Tell us about those.

23:25 Panelists: Anthony, do you want to explain this one? So, timing attacks, there's two brackets this falls into. One, if you're doing any form of security sensitive operation, like let's say for example, you're checking a password is valid. The way a lot of code works, is it might say, well, it will say, well if the password is too short, or too long, then don't bother checking the password, just fail out straight away. And an attacker can use this to work, okay well what is a valid password, to decrease the password it needs to check?

23:55 Michael Kennedy: I see. So if you're going to do like a dictionary attack, and you realize, well it's zero milliseconds for anything under seven characters, we'll start there.

24:04 Panelists: Exactly, exactly. So if you're doing particularly some cryptography, the idea is, it's meant to have an approximately equal amount of time, irrespective of what an input you give it. This also is another set of attacks around time of check, time of update. So if you're doing certain checks, and then doing stuff that depends on those checks, make sure those checks are around the same time in code, as they are that you're doing it. 'Cause otherwise there is a gap between when you do that check, that security check for example, and when you do with that task, or that operation that requires, as a result of that check. That can be exploited too. So there's... There's some of two areas here, so.

24:45 Michael Kennedy: That's pretty interesting. I hadn't really thought of this sort of information leakage around that. So I want to give a shout out to a Python package, that I think just is really amazing. We talked about password checking and stuff, called Passlib. Are either of you familiar with Passlib?

25:00 Panelists: No, I'm not.

25:01 Michael Kennedy: Yeah, so Passlib is really awesome, because you know, one of the bits of advice is to get a random salt, and mix that in when you generate the password, right? Or when you hash, and store the password. And then also make this computationally expensive to guess. So Passlib is like, there's like one function of like encrypt, and one function like verify. And it will, you give it a plain text password, and it will take that, and it'll fold it like 150 thousand times, with custom salts, for that particular user. And then it can check it. But it takes like point two seconds to determine whether it's right or wrong. It doesn't even just check the length, so it's a really nice way to sort of add a few more layers there.

25:43 Panelists: Yeah, so the other one I recommended was part of the standard library. But it was only added in three point five, and that's the module called secrets. And it has a method called compare_digest, where you can basically give it two values, and it says are they equal or not. So that's where you would say, if the actual password equals, equals, the password the user entered, and statements like that, are the type that can be left open to timing attacks. So compare_digest basically makes it impossible to do that.

26:10 Michael Kennedy: Yeah, that's cool.

26:11 Panelists: So one piece of advice that I have around, if you're doing anything like password management, or and cryptography stuff, generally speaking, don't write it yourself. Use a library off the shelf that other people have used and vouched for, 'cause it's very easy to, if you do crypto wrong, it can be worse than having no crypto. 'Cause for the... For all the, for all the false assurances it will give you.

26:36 Michael Kennedy: Right, you think it's fine, but you know, I don't understand that. I base64 encoded the password. They can't get that back out of the database, come on.

26:44 Panelists: Of course not, of course.

26:45 Michael Kennedy: Yeah, that pass level one I talked about the way, they have like a list of all the support algorithms, and the ones they recommend, and they're constantly checking those. So I think it's bcrypt, and sha512, right now that they're using.

26:55 Panelists: It'll be bcrypt, and probably the PBKDF2, or they're the two ones that people tend to recommend these days, so yes.

27:01 Michael Kennedy: Yeah, nice. So one that I think is kind of scary, because it... It's an exact opposite, or in contrast, to what makes Python awesome, right? Like, you know, import antigravity, it sort of captures the joy of Python, or you just import anything, and it's just there, and it just works. But it's possible that you could've installed something bad, right?

27:26 Panelists: Yeah, absolutely, and I think, not just install something bad, but the way that Python imports work, they're really flexible. You can override all sorts of things, including system, like, almost language key words. So you can override the print function, or the assert statement, or you can do all sorts of crazy things in imports. So I think one of the challenges with Python is that, if you have a package somewhere in your site packages, basically in the import path, that does something malicious, it can be very difficult to detect that. And because you're site packages is almost like a tier, so you got like a system level one, and then you might have a virtual environment one, and then maybe there's another one that you use as well, where you might import stuff from somewhere else than your Python path, then when you import something, you're going to never actually know, unless you go and check, what its imported.

28:19 Michael Kennedy: Yeah, and it can do really bad stuff like, you know, just the way you're talking, and I was thinking, okay so I write a package, the import statement is effectively execute __init__.py. Maybe in that section, I'll see if I can go and find SQLAlchemy, or some database connection, and then I'll monkey patch that over for the connect, so I can grab your connection string, and then pass it along, so you think your app is still working. Or I mean there's all sorts of nefarious stuff you could do, right?

28:45 Panelists: Yeah, exactly, and I think it's just people put a lot of trust in their pip install statements, in terms of, not only what package they installed, but what dependencies that package had, and what dependencies their dependencies had, and what ended up getting installed, and whether that any of those have actually polluted your site packages. So basically if you're importing, even a standard library module, like is that... Has something else overloaded that, and is that import basically changing your global name space.

29:18 Michael Kennedy: This portion of Talk Python to Me, is brought to you by, us, over at Talk Python Training, we're building out our library courses and that library's growing each month. That's why I want to take a moment, and tell you about a special offer we have. It's called the everything bundle. With it, you get well, everything. Every course we have in our library, including the ones yet to be published this calendar year. Many online training companies have subscriptions and discounts if you buy them a year at a time. Our everything bundle is like a subscription, but it's way better. With subscriptions, the moment you stop paying, you lose access to everything. With our everything bundle, you keep access to our courses, forever. Any course published the year you bought the bundle, or sooner, is indefinitely yours. Even if you never renew. Check out what's available at training.talkpython.fm. And if you're looking for a way to support the podcast, taking or recommending one of our courses is the very best way to do this. Thank you. That sort of hints at a really scary scenario, because I'm pretty careful what I install, but I don't go and check the dependencies of everything that it depends upon before I use it. I'm like, this looks like a reputable package. I'll go ahead and use it. But it hints at, almost like a supply chain challenge, in that like imagine I find some not very popular package that something popular is based upon and then I go do a PR, that's sneaks in some extra sneaky dependency, that is actually the problem that people don't realize. And so when that gets pushed out to be updated, you update your thing, all of a sudden, you're indirectly pulling in this thing. Because some guy was like, yeah looks like a good PR, I'm busy, but we'll take it anyway, go ahead.

30:59 Panelists: Yeah, certainly can be. So I can... Oh, there isn't really one.

31:03 Michael Kennedy: Do... Or get to like the doctor, don't do that. It hurts when I do this. Don't do that. Well, you do reference the service that I'm a fan of, so tell people about it.

31:12 Panelists: Yes, so pyup.io, basically has a sort of a data base of packages, and versions of those packages, which have known vulnerabilities. So this links to one of the other things I put in the article, which was not patching your dependencies, which is a pretty common pattern, where people say, okay I'm going to get on my dependencies, and then I'm going to do pip freeze or something, and I'm going to put that in to my requirements.txt file. So I basically pinned which versions that I know work and no one ever touched that file. So like that's probably one of the scariest things, is you've said, these are the versions, these are the ones we tested with, but no one goes and checks each packages, or each dependencies website, and sees the notification that says, oh yeah sorry, there's a massive security hole in version 2.9.6. Please update, update to 2.9.7.

32:03 Michael Kennedy: And it's the dependency, maybe the dependency of your dependencies thing. It's like even if you were a crazy diligent, and you went and checked all the stuff you installed, that's not even enough.

32:12 Panelists: Yeah, exactly, so pyup.io, basically has a database, a freely available database, where you can look up bad versions of packages, that exist on PyPI. And they have a service where, they can actually go and scan your requirements.txt, if it's on a GitHub repository. Or they have hooks, where you can use it with other services, like GitLab, and if they basically say that there are newer versions available, or this is a bad version, then they'll give you a notification. So I guess that's one of the better ways of approaching the problem. And this is probably the point in my article that got the most negative feedback from people, they said of course, you have pin dependencies. Like, you know, you can't just willy-nilly, install the latest version. But pip does... It does have version ranges. There's a PEP for that, so you can say, you know, I want this minor version. So, I want version 2.8, up to 2.9. And then if they release the 2.8.1, or a 2.8.2, then you'll automatically install the right version. And if you hope, that people use sematic versioning, the API itself, and the functionality, shouldn't have changed. And of course you've got good test coverage anyways, so you'll catch it.

33:21 Michael Kennedy: That's a really good point. The problem is pip freeze doesn't do that, right? And that becomes a ton of work on your side of things. I use PyUp for my stuff, so like the training website, the various podcast websites, and a few other things. I have it hooked up , and I will get weekly pull requests, these three packages have changed. And it could be like deep dependencies. Here's there change log, here's the new version, and it's just the PR, which patches the frozen packages in my requirement.TXT. It's really nice. Anthony how do you think about this?

33:52 Panelists: Yeah, so one thing I was going to add is, is that you can never predict when a package that you thought was good, may turn bad. People might write a package, and think, yeah this version is great, and then someone, somewhere, finds an issue with it. So the key here is a regular monitoring of what you're doing and a regular patch cycle. 'Cause he said, you never know when something's going to happen, so you need to make sure you're looking for it, and that turn around time, is as short as possible. So okay if the focus here is more on your operations, how do you manage your system, as opposed, and discernibly how you program it? But nevertheless, that's important.

34:25 Michael Kennedy: Yeah, I think another step there, is you have to proactively be applying these changes. It's one thing to notice there's a problem, it's another to notice that pyup sent me a PR that says, oh you're depending on this version of, you know, a JSON parser, or something, and it has this vulnerability, you need to fix it. It's not a to go, yeah. And now I'm patching the server, right? You think, look at what was Experian, right? They were hacked with a known vulnerability. It was... Everybody said, this is ultra bad. You need to drop what you're doing, skip lunch, and go fix it. And it's just, well we work in this big company, we can't be bothered to change this, 'cause if it breaks, this is not my site, but if I break it trying to fix it, I'm losing my weekend, so I'll let someone else deal with that on Monday when they get in. And then, you know, 143 million people, lose all their credit and personal banking details, me included. Yeah, but I mean, what are you going to do, right? You've... I think there's like another layer that goes on top of this. Like you have to act.

35:24 Panelists: Yes, Yes. I mean it's a patch management aspect of your server maintenance, or system maintenance. I mean as Ant said, there's tools inside Python, but you need to use them, and you need to be using them regularly. And you need to have that, you know, I do need to fix it now, so how do I decrease that turn around time, so as small as possible.

35:44 Michael Kennedy: Yeah, yeah, yeah. Ant, what do you think about speed to actually deploying the fix? Like are there, like continuous delivery bits of magic, that you people would be willing to rely upon? Like it says, massive security vulnerability, we will let it automatically publish this, if the test passed.

36:00 Panelists: I'm not sure

36:00 Michael Kennedy: For Example.

36:01 Panelists: If your test passes to a release to go through some sort of UAT, it depends I guess on the... It depends on the project, and it depends on what it's for. Like if it' a... If it's an internal web application, then you know, it's unlikely, but you also want to make sure that thing gets patched, and updated as quickly as possible. Because the cost of... The cost of down time is one thing, probably smaller than the cost of attack, or the cost of compromise. So I guess it's kind of a looking at it from that angle. Another thing I guess I want to talk about, is that the way you, as a developer, talk to operations, assuming you have an operations team that you're talking to, and that's not just another hat you have to wear, and the way you talk about what versions of the dependencies your package depends on, and how brittle that is. 'Cause something I've heard a lot is people say, never no, don't touch my dependencies, 'cause I know that they work, and you're probably going to break the code. So from an ops fact, you know, angle, they're like, well we're going to look after all the system patching. But the application stuff, that's you know, they've told us not to touch that, and to leave it alone, otherwise it's all going to go really bad. And if they touch it, and they try and patch something, then the dev teams going to be like, oh well, you know, you've been changing the code, and you've changed the dependencies, and we didn't ask you to do that, and that's why it's breaking. So I guess it's a conversation between the two teams, or if you've got dev ops, and then having a conversation, about how you try to automate some of that stuff.

37:27 Michael Kennedy: Yeah, the more automation, the better. So the next one you have on your article, was surprising to me. I didn't really think about it, but I guess it makes sense, is temporary files.

37:35 Panelists: Yeah, I'm lucky enough not to have to use those very much, in most of the stuff I write these days, but they're actually very common vulnerabilities.

37:43 Michael Kennedy: So apparently there's a mktemp function, that'll generate a temp file. I didn't even know about this. I don't use temp files very much either, I guess.

37:50 Panelists: Yeah, it's an old one. And I came across this when I was doing, building the course, and moving Python 2, to Python 3. 'Cause one of the recommendations is, that you don't use the Python two functions, for creating temporary files, 'cause they have known security issues in them. So you're kind of digging into that a bit deeper. So there's a tempfile module, which is the one that you should use. And there's a function called mkstemp, which you should use to generate temporary files.

38:15 Michael Kennedy: Is that for secure?

38:16 Panelists: I'm pretty sure S stands for secure, yeah.

38:19 Michael Kennedy: Nice, okay. So the problem is, there could be timing attacks, or if you hit the time just right, like you could create the temp file, and then you could swap out the data before they redid, or other bad things like that, right?

38:30 Panelists: Exactly, so the reason the old one is bad, is because it will create the file first, and then it will open and load the file. So what can happen is, someone can sit there, scanning the file directory, the temporary file directory, and an attacker can virtually sit there looking at it constantly. And it's things they see on a file, they see a file pop up. So the file handles been created. And then they can go and dump a lot of data in there. And then you open up, and then it's all changed, like basically, it's a way of injecting data into application.

39:01 Michael Kennedy: Yeah, that sounds bad. So and another one, you kind of touched on this before, is parsing other file types can be really bad. And I kind of rifted on XML being bad because it was old, and complicated, but YAML's kind of new, and awesome. That probably is the bad, right?

39:18 Panelists: You know this YAML one, is so... Really hardly anybody knows that you can do this, because when you look at the example, you think, why would they allow that to happen?

39:28 Michael Kennedy: Wait, hold on, hold on. I think, exactly, like maybe you shouldn't tell anybody about this. Because you're going to tell people they could do it as much as to protect themselves against it.

39:36 Panelists: Exactly.

39:38 Michael Kennedy: No, I'm just kidding, go ahead, tell everyone.

39:39 Panelists: So I guess the most popular package, for reading and writing YAML files, is called PyYAML, and it has a method called yaml.load, or yaml.loads. And if you actually read the documentation, it says in big letters, warning yaml.load is not safe, essentially, because you can run any Python function, by putting special characters in the YAML file.

40:05 Michael Kennedy: Yeah like, !!python/object/apply:os.system, and you know it's some form of like Python code, or calling some sort of subprocess, or all sorts of bad things. Like that's incredible, that you can do that. That you can just say, shell execute this, in my YAML file.

40:23 Panelists: So you can basically put a special, it's like two exclamation points, and then a special path, and then the name of the function, in the standard library that you want to execute, and the parameters. Then if you call YAML.load, and the YAML text, or the YAML file has that basically, that special syntax in it, it will just execute that locally. So you can imagine, like if you had a web application, where you are asking people to provide some simple YAML input to describe something, or you are loading something, to configure something. I mean an example that I used in there was, you know, I used YAML a lot with Ansible, which is like a network automation tool, and they had a... They had the vulnerability, they had the same vulnerability, 'cause in their product, called Ansible Vault, they were loading it using YAML.load. And the people were like, oh awesome. I can just like pop a shell in this box, instead of providing that password.

41:15 Michael Kennedy: That seems amazing. Anthony, do you use Ansible, or work with YAML, and worry about these things?

41:22 Panelists: Yes, I mean this is a perfect example of something that really... It's like, for those, if any of your listeners are familiar with Javascript, you use to have the eval, that use to run to load in JSON, but they changed that to parse, 'cause eval was inherently unsafe. And this is an example of a function, which is just, you just goes on the do not use list, for anything that is serious. Alright, you just don't use it. If there's no equivalent on it, then we'd look at something, something else. Because there's, unless we go and rewrite it, there's no work around.

41:54 Michael Kennedy: It's basically like giving people, like just dollar prompt access, like type here. What do you want to do on the server?

42:00 Panelists: Exactly, exactly. To be honest with you, this is one of those things, when I read something like this, the first thing in my head is, what were they thinking?

42:08 Michael Kennedy: I am with you. So first...

42:09 Panelists: Seriously.

42:10 Michael Kennedy: Yeah, so Ant tell us the fix, what is your fix here?

42:12 Panelists: Okay, so there's two fixes, and I only found out about the second one yesterday. And I think it might have something to do with this article. The first fix is, that you don't use load. You use safe_load, which...

42:25 Michael Kennedy: Of course.

42:25 Panelists: Of course. So in the same way that you have to use MKS temp, instead of MK temp, you should use, however I guess, explicitly saying you want to do things safely, is a bit of a anti-patten. So I did see there was a pull request, which has been merged into PyYAML, to make the safe version the default. And you have to explicitly ask for the unsafe version. However, I think that's only been merged in the most recent version of 4.1, and then if you ignore all of our prior advice, about updating your pip dependencies, then you're never going to see that anyway.

43:00 Michael Kennedy: These do interplay, don't they? So I was definitely thinking of that API design, sort of experience, in like wait load, and then like the safe unload, is what you're really supposed to do some of the time. Like this does not help people fall into the pit of success, right? Like to me it seems like, if you don't know what you're doing, it should default, or just lead you down the path of, well do the safe one. And if they need the crazy, you know, run this shell thing, like make them hunt for that. Don't make that the default, until they know better, right? Sounds like at least they've gotten that working now, like going.

43:35 Panelists: Yeah, exactly, and I mean the advice that I would give to anybody who would designing their own API's is, security by default. What you do, the less obvious way of doing things, this fancy way of doing things, should be the secure way. If you have features that are potentially unsafe, by all means, expose them. Then make the developer, or the user, specifically ask for it, so they can accept and manage the risk.

43:59 Michael Kennedy: Yeah, that's perfect. One of the ones that I felt was kind of obvious on this list is, is obvious because I've been around for a while I guess, are is this concept of pickling. And pickling is the act of taking, more or less, a binary version of a Python object graph, putting it on disc, and then re hydrating back into objects, right?

44:21 Panelists: Yeah, and it's typically used in sort of interprocess, or interpython communication, or dumping an object somewhere, and then loading it again somewhere else. And so it's kind of built into the standard library. It's been around for a while. And before things like, JSON kind of became really popular, I guess it's one of the preferred ways of communicating, or sharing data between Python processes. The problem is that, it has a number of fairly well documented security vulnerabilities. I mean if you're loading up a pickle file, you can basically put things in the pickle file, which cause it to run any Python process. Like if you basically create a new class, and then you declare something called __reduce__, then the contents of the __reduce__ method, if you return back a tuple, or you can basically, the tuple that you return can be the name of a standard library function, and its arguments. So basically that's again, where you do os.system, or a popen, and you basically pass it on the argument. So instead of loading this nice pickle file, and you continuing with your day, basically you load a pickle file, and it just runs commands in your local machine.

45:32 Michael Kennedy: Yeah, that's not amazing. So again one of these sort of don't do this. It's extra hard to check too, because the thing your delivered is a binary blob, so how do you know whether it's safe or not? You can't even look at it. It's not even like the YAML file, where you're like, wait, wait, wait, what is that double, double, extra long Python thing? That doesn't look right. Right? This is just you know, one zero one one one zero share one, seems okay.

45:56 Panelists: Yeah, so there's not really a work around for this, other than don't use pickle, or don't try and unpickle things, from an untrusted source. But then, I don't even like saying that because, it's that kind of assumption, which attackers use for using it attacks, combining them together, but Anthony knows a lot more about that than I do.

46:15 Michael Kennedy: Yeah, it's chaining them, right? It's like you lose one, to get one layer in, and then another, and then another, yeah?

46:20 Panelists: Ant's got a very good point, the way a lot of attackers compromise systems, is they won't go after the top tier, the most important, the most visible ones, but try to look at, maybe the second, or third tier systems, ones that people may not have paid as much attention to, or made enough, as much effort securing. And if they can compromise those, they will use those as a foothold, to go after things that people perceive as important. So if I compromise an app, and it's communicating via pickels, to other apps, for example, that can be how the exploit occurs. So it's good to keep in mind that every system you write, has to consider security here, as Ant is saying. And follow Ant's advice, and looking at these ten topics.

47:06 Michael Kennedy: Yeah, I mean, maybe this is some wimpy little app, that it's just like some reporting thing, but you could use it to get behind the firewall. Or maybe you could pickle some bad stuff into a share Redis cache that the other system might read, and then, you know, you just level up step by step, right? This so called lateral movement.

47:22 Panelists: It is being recorded, you're right. Exactly, exactly, and look three, four, five hops, for the compromises is not unusual. And when you see it going, you realize how good some of these attackers actually are, but I digress.

47:34 Michael Kennedy: That's right, that's right. So I guess the last two kind of blend together a little bit, in about not patches in your Python runtime. Sort of the main one, which you give, just go to the open a shell, and just type python3, or something, or your dependencies as well. And I heard that you don't really need to patch your Python runtime, because there's fewer days, that sometime appear, in like your OS, so you can just like, this is not worth bothering with, right? Was that what that crazy comment was about? I can't remember.

48:06 Panelists: There was a comment along those lines, they were like, aww but why do we bother have... Why do we have to patch Python, because their probably just going to hack us anyway, so what's the point? If only. If only it worked that way.

48:14 Michael Kennedy: I think that side, I mean we touched on that at the beginning a little bit, and that is sort of a sense of despair that people have. You're like, look I can do all these things that I'm supposed to do, but as soon as there's some sort of zero day, or O day in my system, you know, all bets are off. I'm not going to be able to defend against that. I don't know what zero day there is in, you know, nginx unit. And so forget it, I'm just not going to worry about security. And I can totally understand how people feel that way, but there was some interesting analysis and reports saying, that even state sponsored actors, of hackers and stuff, primarily use super boring stuff. Like all the things we've already been talking about, right? Like SQL injection, and other boring, unpatched things.

48:57 Panelists: I mean, zero days, yes they happen, but as a proportion of total security incidents, they're actually relatively small. Particularly for the well known, well trusted, packages and products that are out there. I think, if this is one of those cases, where people need to get their own house in order, before they throw stones, if you know what I mean, so. But I mean once again, I mean... I mean most of this stuff is relatively simple, once you understand what you need to do. So this is a question of putting time and effort into it, that's all.

49:29 Michael Kennedy: I think there's a difference between the NSA, or some other country, is trying to literally get into your thing, or I'm on the internet, and people are rattling the doors, to see if their open, and they're not going to spend a full week trying to get in my system, 'cause they know there's thousands that just have SQL injection, or some other random thing, right?

49:47 Panelists: Yeah, and look to be honest with you, if the NSA really really wants to get into your network, the version of the Python package you're using, is probably the least of your problems at the moment, so.

49:58 Michael Kennedy: Yes, exactly, exactly. Plenty scary, but we're not going to think too much about that again. Ant, what you're telling me is, I need to install Python 3.7 'cause it just came out, things like that, right?

50:09 Panelists: Yeah, I'd actually say, this is probably controversial, but I wouldn't install Python 3.7 until 3.7.0.1 comes out. Generally, I...

50:19 Michael Kennedy: Yeah, yeah sure. But maybe patch like if there... Were like 3.6.6, or 3.6.7, whatever the next one there is.

50:26 Panelists: 3.6.6, yeah. I'd go with 3.6.6.

50:28 Michael Kennedy: But it's part of that stain on top of things. I wish, PyUp, actually had a check to say, you're Python version is 3.6.6, and it should be 3.6.7. Something like that.

50:38 Panelists: There is another tool, which is open sources as well, called InSpec, and it's made by the same people that brought you Chef. So it's brought in Ruby, but it does actually have a bunch of hooks for Python applications. And I know that it does do virtual environments, and also checking versions of packages in production. So you can say, make sure that none of the servers in production have this version of Python. And make sure that they don't have these versions of these packages as well. And you can do that in InSpec, and basically declaratively saying, here's our security rules, and it will go and scan through your installations for your service for you, and that should give you back a report. So InSpec, I guess, would be the way to do it, or a tool like that.

51:21 Michael Kennedy: Yeah, that makes a lot of sense. Alright, well I think, hopefully people learned a lot from those ten items. I mean there's certainly a couple of them that I had heard of, but others were new to me, and it's always good to be aware of these things. So thanks for putting that together, and you... Both of you for sharing it here. So Anthony, how do I sell this to my... You know I work at a startup, the management just got VC funding. We're supposed to do growth, growth, growth. Were trying to figure out new features, so that we get this thing to get out. How do we get ourselves to worry about this?

51:53 Panelists: So, well the first thing is, to understand any legal or contractual obligations that you have. So if you're in Europe, for example, you have to follow the GDPR, the new general law to protection regulation that's there. If you're handling credit cards, for example, you've got PCI DSS, the payment card industry data security standard. These are the non-negotiable things you have to do. The second thing is, if you have any security executives, or ladies in your organization, that's a CSO, or if they have corporate policies, security policies, you need to follow. They're are two things, but beyond that, one is just look at the newspaper. Reputation, not in financial damage, is real. It happens. We've all seen or heard of companies that have been hacked, and thinking, gee I wish I weren't them. I wish I was not them. So, don't. Don't be them.

52:45 Michael Kennedy: Yeah, exactly. Well, and also, I think it comes to do with culture a little bit, right? Like if the culture is, do not change this application, do not touch it, because if you break it, you're going to take down some part of our business, and we're going... It's going to be so bad that that thing ossifies, and it's basically like no, it's kryptonite, nobody wants to touch it. I'm going to stay away from that. Yeah, it probably is got some security issues, but I'm not touching it, 'cause I will be punished to know end, if I'm the one who breaks it. I can see that happening a lot.

53:14 Panelists: Yeah, it is. And this comes down to your general culture around, as Ant said, test coverage, refactoring. If you have stuff that you can't touch, it's going to cause you security problems. If it's stuff that you can touch, you have a fighting chance of solving them. So that comes down to, once again, to a... The term that uses risk management. Is your management happy to accept the risk that you're going to have an app that will eventually cause you a problem?

53:38 Michael Kennedy: Right, it's sort of the consequence of failure there. I mean, look at WannaCry, and Windows XP, a lot a lot of these... Like there's so so much damage from that, right?

53:48 Panelists: Yes, and it's particularly if you're in a small shop, if you're in a startup, reputation is big early on. So you need to make sure, that you can maintain that trust, that you're going to need from your first few customers, so.

54:01 Michael Kennedy: Yeah, and you probably have an advantage, in the sense, that you don't have big data centers with legacy machines laying around. You're probably on the cloud using modern tools 'cause you just started, right? Chances of continually keeping that upgrade train running, is probably easier.

54:14 Panelists: Exactly, exactly. It's all green field. You don't have to keep older stuff running. Exactly, exactly.

54:20 Michael Kennedy: Yeah. Alright, we're getting pretty short on time, and I'll be respectful of both of your times. But Ant, maybe you could tell us really quick, some places to learn more about security.

54:28 Panelists: Yeah, I guess then one, two products I want to call out. I said, there's a number of projects with the same kind of name that's related to goats. I'm not sure where the goat name came from originally, but basically there's a project called Web Goats, which was originally done as a how not to do things, open source project, so basically include all of the top ten most common vulnerabilities. And I kind of don't know what language it was written in, probably Perl, but there's a Python version called PyGoats, and there's a Django specific one called DjanGoat, which I guess will have in there... Which I guess we'll have in the show notes, but if you actually look at that, it's got all of the... The DjanGoat's one really cool, it's got all the stuff you should never do, with Django projects, like leaving debug enabled, for example. But basically how to do the, all the kind of vulnerabilities we've talked about as well as the other ones in a project. So it's kind of like a how not to do things project. And I think it's good if you want to learn how things are done. And also it has instructions about how to break it, how to use those vulnerabilities. So I would start there, and then if you know them, then you can start doing things like, doing scans through your source code for those particular types of vulnerabilities or those functions, and seeing if you can find bugs in other places.

55:45 Michael Kennedy: Yeah, that makes a lot of sense. I really like this goat series. That's pretty interesting. One thing I want to give a quick shout out to, that's in your neighborhood, and is a podcast called, Risky Business. Have you heard of it?

55:57 Panelists: I listen every week, yeah, love it.

55:58 Michael Kennedy: It's fabulous. Man, those guys do such a good job. It's like headline news in security and tech, the programmaning security. It's really great. And just listening to that, you learn a lot sort of by osmosis, I think. Alright, well, I think just we're out of time. We could go on and on and maybe we'll have to do another episode on this. But that was really helpful and insightful. So thank you both. Since there's two of you, I'm going to ask two questions at the end, but the same one. We'll just do the notable PyPI package. So is there a package, maybe related to security, that people maybe haven't heard of but you want to throw out there to let people know about it? Anthony, you want to go first?

56:34 Panelists: I had a couple, but if one of those things that I think, rather than a package, I think people need to take a step back, and realize that security is a mind set. Yeah. In that, there's no package that's going to make your app secure. So I'm going to twist the question a little bit here. It's about keeping abreast of what's going on, and keeping current, and getting knowing to learn. And its an area that can be fascinating, can be real interesting, so.

57:01 Michael Kennedy: Yeah, excellent. Ant.

57:02 Panelists: Yeah this one actually hasn't been released yet, but Brian and I were working on a new Pytest plug in called, pytest-requests. And by the time this episode goes to air, it will be out. And it will be wonderful. So I'd recommend you check it out.

57:13 Michael Kennedy: Oh, that sounds really fun. That's awesome. And I also want to give a shout out to your Python 3.7 course. You just did a new course on Python 3.7. I thought it was great.

57:22 Panelists: Thanks, yeah, that just came out. Just in time for the actual release of 3.7, which is good.

57:24 Michael Kennedy: Yeah, you beat the window by like a week or something. Maybe just tell people super quickly where they can get it, and what it's about.

57:32 Panelists: So the course is on Pluralsight, if you have access to Pluralsight, or you want to sign up for a trial, you should be able to watch the course. It's less than an hour. And I basically go through all the major new features in 3.7, how to use them, how they work, how to configure them, as well as some of the other benefits. So it'll take an hour of your time and you'll be a Python 3.7 expert by the end of that.

57:54 Michael Kennedy: But you should wait till Python 3.7.0.1 to actually get going, maybe?

57:58 Panelists: Probably, but that'll be weeks away, I reckon.

58:00 Michael Kennedy: I reckon, yeah, I already installed 3.7, but I have 3.6 on my machine just in case I need it. Alright, awesome. Well yeah, I enjoyed it so good to let people know about that. Alright both of you, final call of action, people, maybe they're thinking about the software that they have, what's the first thing to do to start to address this?

58:16 Panelists: Anthony? The first thing is, is take a step back, and think, well what is the most important things that my app is protecting? What are the most important business processes? Or what do I have that's there? And to think, how can I protect it? How should I protect it? Is what I'm doing, what I need to do?

58:32 Michael Kennedy: Alright, excellent. Ant, anything to throw in on that?

58:34 Panelists: Yeah, I'd say just don't be intimated by security in general. Just start simple, and be willing to learn, and also be willing to learn from people who have a lot more experience, of which there are plenty of people out there.

58:46 Michael Kennedy: Yeah, it's definitely a different way of thinking, and it's pretty fascinating. Alright, well thank you both for being on the show, and sharing all this stuff. It was great.

58:54 Panelists: Thanks, Mike. Thank you Mike, great to be here.

58:55 Michael Kennedy: Yep, bye bye. This has been another episode of Talk Python to Me. Our guests on this episode have been Anthony Shaw and Anthony Langsworth. This episode has been brought to you by the Test and Code podcast as well as Talk Python Training. Keep up with the latest news and become a better developer by listening to Python Bytes at pythonbytes.fm and Test and Code at testandcode.com. Want to level up your Python? If you're just getting started, try my Python Jumpstart by Building 10 Apps or our brand new 100 Days of Code in Python. And if you're interested in more than one course, be sure to check out the everything bundle. It's like a subscription that never expires. Be sure to subscribe to the show, open your favorite podcatcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm. This is your host, Michael Kennedy. Thanks so much for listening. I really appreciate it. Now get out there, and write some Python code.