Practical Django Secuirty

Speaker 1: Thank you very much. Uh thanks for coming to DjangoCon. Uh wonderful speakers here. I hope I can move up to the podium. Now uh I generally speak about Security in the Django meetup in New York. And my first time I did this, I spoke for about three hours and I realized that maybe I should tone down the slides a little bit. And these days I largely speak about attacks, but when it came to posting content for DjangoCon, I figured, like, let's not look at attacks, attacks change, uh also There's a video. I don't want someone learning the wrong things from this talk. So I've come up with a little bit of a unique approach to how we're going to go through security. So I'm employed by a wonderful company called Genesis.

Speaker 1: I used to be employed by a company called Manasano. How many of you have heard of Manasano? How many have done the crypto challenges? Okay, good. So at least we have some people. I did uh web application penetration testing for about two years. Uh I've moved over to Genesis to do it more uh to to own security in-house, and I like to stay employed, so I'd like to mention that the contents of these slides are my own. Now, when it comes to speaking about security, it gets really tough. Yeah, everyone you're always taught about security. They drag you into a big conference room in these large corporations if you work in one of those or in a small place and you hear about it, you read about it on Hacker News and on Reddit. about different hacks and it's really it's it's a hard problem. It still exists.

Speaker 1: And uh the re one of the major reasons for that is that the your app or your app ecosystem is only secure with its lowest common denominator Take Google, for example. A one cross-site scripting bug within one Google app affects every single Google app because they implicitly trust each other. Now, that's really tough because the surface is we gets really, really big. Also, security is constantly changing. What was good yesterday is not good today. And as a caveat, these slides work for today, will probably work a little bit more, but you should take these points down, research them further, because they may change. So let's look at what we can do to change that. Now, if you want to break down security con

Speaker 1: vulnerabilities into two categories, they can be broken down rather simply. There's either a lack of or improperly designed or improperly coded security controls, and these will cause you to be vulnerable to attacks like denial of service and where you don't have rate limiting, authentication bypass, because your authentication mechanism isn't secure or is susceptible to bypass. And then the worst and most common is improperly implemented cryptographic primitives, which you know you're encrypting the data, the data looks encrypted but can easily be decrypted or Can be modified. And then there is mixing data up with code, and these largely run around with the remote code execution vulnerabilities.

Speaker 1: Now while there are obviously their uh applications that have remote code execution interfaces built into them. With stuff like SQL injection and cross-site scripting in where an attacker can make their data execute as code on your server or at least on your c or or within the context of cross-site scripting within the client's browser. Largely involves the data and code being mixed up. So let's look at these things in a little bit of a different way, right? So as opposed to looking how to prevent the attacks. Let's learn let's look to build our software to be more robust. Let's not look how we're being attacked, let's look to build better software. Now Every language, every program has side effects. But there are side effects that we can prevent.

Speaker 1: And I feel that one of the first things in making a more secure program is building software that is incredibly assertive. You must to the to the best of your ability assert as much as possible what the user is giving you is what you intend it to be, not what you think it's going to be, what you intended. And that's very important. And the Python Zen Has this where it says explicit is better than implicit. Don't just take the input from the user. Assert it. Make sure it's exactly what you want. Now let's look at the easy one, which is mixing code and data. And when we talk about mitigating cross-site scripting and SQL injection, we talk about statements like output encoding.

Speaker 1: or prepared statements or parameterized queries. And these these statements sound very nice. And you know when when you get hit by a cross-site scripting log, they tell you, oh, you you have to uh outputting code and you have to or when you get hit by SQL injection they'll tell you you have to you have to use uh parameterized queries, prepared statements. But these are stopgap measures. Let's look at what these things actually are. So when we get hit by this bug, for example, let's say SQL injection, we have a SQL query. We've got data from the user. Now, do we know what that data is? Well let's say it's supposed to be a number, or let's say it's supposed to be text, right? Now it should only be text, and it should only be considered text by our SQL Server. So if we explicitly put it into that category, at that point we've mitigated it.

Speaker 1: And that's what prepared statements are. Prepared statements Parameterized queries, they're called both things. That's why I keep on using both of them because everyone, like literally in in every different app uh in each app app ecosystem, they have another way of saying prepared statements or parameterized queries But they they they mark, they they explicitly tell the SQL parser, this is data. Do not execute this. Insert this when you need the data required in this location. You explicitly mark that as data. When it comes to output encoding, when you're reflecting user data on the page, at that point you have the ability to You're marking that user data.

Speaker 1: You're marking that user text or user bytes as data. You're telling the HTML parts, you're telling the JavaScript engine within your browser not to execute that. Now, this should be a general rule, and this is one that I follow, and that should be it that I feel that many of you should follow as well. Be assertive. If you don't know what it is, find out where it's going to be used. And whatever you do, you will not get hurt if you mark it as data. Like marking it as code is a risky option. Try not to go in the risky side. Now, let's look at the security controls. So, this is where it gets really tough. Because security controls, you have to understand attack surfaces, you have to understand threat modeling.

Speaker 1: You have to be able to build Your security controls in a robust way, and that's tough because the current security controls that we all use every day Have been a cumulative set of knowledge, of research, around these security controls, and we have only gotten to this point because of all the attacks that they've been hit by. We only have security controls because we need them. We don't have them because it was an initial thought. Security is always an afterthought. It's only after an attacker comes. If a bank didn't need a vault, they would not invest money in st in a vault, but they need one. And then as people as banks as as the vaults have been broken into, so too the vault technology has evolved. So what's really important to note is if you're going to ever build security controls, if you're going to ever implement them or do or

Speaker 1: use them, use popular ones. Now what I mean by popular is use ones that industry leaders use. You can find strength in numbers. Right? Do not use one that one or two people use. There are many times I will go online on GitHub and see a new model that's great and has awesome functionality and contains an authentication bypass. Or contains a security bug that you've now opened the that that it that a unsuspecting user is actually gonna just jump straight into. And The way these these holes get are mitigated, the way that these holes are patched up is by more people using them, by more people reviewing the code. And therefore Building out and helping build a better security control.

Speaker 1: Now, Jamie O helps us with authentication. It doesn't help us very much with authorization. So a lot of us find ourselves writing authorization code. It's really important that when you build this code, these authorization views or authorization decorators, that you Build them, you write them in one you put them in one place. They should not be scattered amongst your application. It's you literally you can take the Python Zen, read it ten times before writing any security control. If it finding having them broken up into many different locations can lead to a vulnerability, especially when you intend to update or mitigate a specific attack, and now you have to do it in every single location.

Speaker 1: Now, it again, as mentioned previously with our data and code example, it's really important to be explicit, but conservative. I'll explain why a little bit later. Now If you find yourself in the case where you have to actually build, let's say, a login system, at that point you need to literally go by the book. You need to get a web application. security book, a good one and have recommendations later on, and you need to go down the list of all the attacks and find out how they're mitigated. You need to look at current current secure or at least secure as of today or now, or at least we we hope so, login systems and design yours to be very

Speaker 1: similar, if not the same. You must understand the attacks and whatever you do, do not write your own crypto routines. So much pain on the internet when I see large people, uh large organizations in GitHub linking to very insecure crypto routines. Now, it's also important to note that you have to understand what you're doing. So you have to be very conservative. In using cryptographic hash functions. And we'll get to this a little bit later. But what's a most of most of all, what's really, really important is Django provides very good and very powerful security routines. It's important that you use them

Speaker 1: because this is what the strength in numbers mean. Django is popular. We're all here. We all represent that community. There are many of us, there are many in that community that are not here today. Django is very popular. If Django implements it, you should be implementing it. Now let's look at some security controls that Django provides. If you need a cryptographically signed something. Use Django. Use the signer that Django comes with. Django auto-escapes. Most un unless you mark it as safe, Django will auto-escape user data. It'll explicitly mark it as safe after auto-escaping it. But the auto escaper only works for HTML markup.

Speaker 1: If you find yourself needing to needing to render JavaScript code, use your JavaScript code, you use JS and code. Now, when it comes also to validating the URL structure, the regular expressions provide a very, very secure implementation of ensuring that the Or at least you should be using it to provide it to provide a stopgap measure that people that shouldn't be hitting certain endpoints with certain data should shouldn't be there. However, it's not perfect. Now for as an example, the default hashers PBKDF2, password-based key derivative function 2. Makes it easier to remember the long list the long the the set of characters when you know what it stands for. But it's set at 10,000

Speaker 1: if you should upgrade that to 100,000 and that's as of today. Warning to all future viewers watching the video or considering this, you you may need to increase that at a later point. Now, if you want if if it slows down your system right now 2. 7. 8, the latest revision the latest version of Python 2. 7 has backported from Python 3 the C fun the C hash function, and you really don't have to worry about it. Another issue that we have is that object permissions aren't present within the framework, and therefore most developers don't think about them. And it's really important to remember that you have to be assertive of which user owns which object. And on top of that, The C Surf implementation in for

Speaker 1: in in Django implicitly trusts the framework. I've got some work that I'm working on that'll implicitly trust the cookie, I'm sorry. And it bases all the C Surf mitigation on the cookie. If you can if you have access to writing a cookie for that domain, you have effectively broken C-surf. Now that is hard, but it's possible. And I'm working on some some Enhancements to the C-surf implementation to mitigate that issue. But let's talk, let's let's jump back a little bit to building our security controls. We mentioned That they should be in one location and we should not repeat ourselves. And all the logic should be very straightforward. This means that when you're using the login

Speaker 1: required decorator, It does not belong in your views. py. It belongs in your URLs. py. How many people have a views. py that's bigger than a thousand lines? There we go, right? How hard is it to give it gonna be to to f realize that you missed one view? It's in your URLs. py that rarely grows larger than a hundred lines. It works quite well. Now, I'm not going to get into the debate of function-based views versus class-based views. Personally, I use class, and you'll see why I like them more later on. But whatever works for you, you know, it's a free framework. Within class-based views, you actually get the ability to create mix-ins by overriding the dispatch method. And we have an example of that here. Here we have, I hope it's easy to see,

Speaker 1: took a screenshot from my computer. Here we have a class-based view mix-in. that is a login required plus it's going to require that uh a specific object Is relevant is owned by that user. And as you see in let's say line five, for example, we we we obtain the target user based on the object. We check that in line nine. Line nine is going to make use of the request. user interface. Now This is obviously assuming that within your application you are request. You're not saving objects as anonymous users And therefore, in line nine, you're you're checking if the user is authenticated, but then you're also checking

Speaker 1: in line nine if that user owns that object. And this is one of the reasons I like class-based views. It allows very easy mix-ins and then you can use these mixins to create views like authenticated tape template view which will just have this as a mix-in on the leftmost side and then have the the regular template view that Django offers and you you have a very simple view and you don't have to worry about putting login login required it also allows you to put all your authentication and authorization code in one easy to find place. Now, that's views. Let's talk about forms. Now just Django forms are fairly secure, they're built fairly well.

Speaker 1: The thing that scares me the most is model forms. How many of you have Rails experience? How many of you know what mass assignment is? Okay, that's good. Just about the same amount of people that have Rails experience. That's really good. So this is something we don't have in Django, or at least we shouldn't, but Mass assignment is a bug where fields within your model are accidentally exposed to the internet, allowing anyone to put any information they want in those fields. Now, I've always I I've written the the the Django documentation taught me to always make use of fields. And uh I very much trust it. I don't use exclude. When you use fields, you're whitelisting. You're saying we only want these fields. We only want to deal with these, with with, we only want to populate these fields in our model.

Speaker 1: And I think this is a very good example of a properly implemented control. It makes it hard for the developer to shoot themselves in the foot, and at the same time, it's also very powerful. Now, well, we've knocked off quite a few things in our list. Let's look about being let's let's talk about being conservative. So uh C Surf is one of the things that is is is is a popular whole that's been exploited and it's it's pretty scary. And one of the problems that that I feel that Django has, especially with function-based views, is their lack of explicit HTTP verb handling. Now, as you see here in my class-based view, I have I'm inheriting from the Django Core view and I have the ability to respond to both a get and a post. But if I don't I don't have any of those methods.

Speaker 1: It'll get a method not the the view will return method not allowed. Whereas a function-based view will always return based on that method. There are C-surf holes that I've found that exist Because functions were expecting a post, but when you gave them a get, they pulled the h the variables out of request. meta and the the C Surf middleware in Django saw get He said we don't have to check for C Surf here. And I and the the view was compromised. So There are there are there is the ability within Django function within function-based use to use a decorator called Allowed Methods. But I'm not that much of a I'm not such a fan of decorators.

Speaker 1: I find sometimes they're left out. And when it comes to writing your own, it can get a little bit hairy But that's just my own personal feeling and you know, don't take it judge it on a case-by-case basis. But I I like to be very conservative, at least when when it comes to my own personal development. So I shy away from writing decorators. I'm using classes and I'm being conservative and explicit about what my view is supposed to handle. Okay, now that we know what being explicit is about, let's talk about crypto. Now I was the original section, the original slides here were examples of how to do crypto properly. And I wrote an example of cryptographic implementation on my blog in Node.

Speaker 1: js. And then someone asked a bunch of questions about it and started moving things around. And then I pulled my slides out of this talk and I want to And I want to shut down that page or at least remove it. Crypto is really hard. Even cryptographers have problems with it, let alone simple humans like us. It is really important to note that if you do don't implement crypto properly, your users can be negatively affected. And therefore, you have to be very conservative with what you do. Using Kiesar, and I'm only giving Kiesar as a recommendation, use Kiesar. When it comes to crypto, use keys are Don't implement it yourself, please. And

Speaker 1: please don't play with keys are. You're modifying keys are, modifying the behavior of keys are vulnerabilities. Now, I have a friend named Jan. Jan and I used to work together at Matassano, and after the work at Mattisano, Jan and I developed an application in Django. And I proposed an idea to use a cryptographic hash to identify a user. And Jan let me know about Jan's rule. Jan's hash rule is simple. Only use a cryptographic hash when you need to. Now, can anyone give me examples of what a what a use case for a cryptographic hash that you absolutely need a cryptographic hash.

Speaker 1: Storing passwords. Um incorrect. Because i these days, cryptographic hashes While they used to be good for for storing hashes for for for storing passwords because they're supposedly one-way functions or they're great compression mechanisms. Cryptographic hashes can be calculated very fast. Passwords you don't want to be able to brute force. So we these days we use uh algorithms that are tunable. Someone mentioned Bitcoin or cryptographic currency. Again, the amount of processing power that the Bitcoin network has practically invalidates anyone that uses any of the SHA. family or even I'm not even gonna talk about MD5, but the the the Shaw family of hashes to hash user passwords, the amount of hashes that are able to generate a second

Speaker 1: Is mind-boggling. So there are two examples of Jan 's hash rule in where you don't use a hash unless you absolutely need to. The one use case I know is if you want to ensure the consistency of a sp of a specific file. And for for example, Git uses hashes to track files. Many open source programs use hashes so people should know if the file has been modified or not. But then again, we need hashes. We need at least unique identifiers that we need to tie back to users. So for that, we have UUID4. UUID4 reads 16 bytes

Speaker 1: out of The cryptographic random source of the operating system, or at least it's supposed to. If you don't have access to it, it'll just use Python's random. So You have to ensure that you actually have access to it. But that's when you need a UUID. When you need a regular just set of bytes that are completely random, just read out of U random. An example of code right there. That number is completely unique. At least I hope it is. Now, you need something to you need something to be signed? Use Django Signer. If you're stuck, you're gonna have to use the J the Python's HMAC implementation. But then again, once you get to the HMAC implementation Which by the way needs a hash. That's another example of

Speaker 1: a primitive that needs a cryptographic hash algorithm. You can get nailed with a timing attack, a side channel timing attack. So really just stay on the safe side, use the Django primitives. Now I deliberately shortened this talk a little bit. Now we got almost 15 minutes. So there can be a lot of questions, but let's I'll end off with a little bit of an appeal. Security is a great industry. It's really good. It's made me a better engineer. And I hope it as if you guys do research. If you do research into security, then you will become better engineers. It's important to note the limitations. The lowest common denominator will never disappear from security, just like the chain is only secure as its weakest link

Speaker 1: But it's really important to do research, look things up, and When building new parts of your application, try to understand the attack surface. Don't only look at what should happen, look at what may happen. And then once you start what may once you look at what may happen, you realize it's a little bit tedious because so many things may happen. So let's just be assertive and ensure as much as we can what should happen. Now, I'd like to make an appeal to a larger community. There is a lot of knowledge that we have within Django about security. There's a checklist that we should be building to help our fellow developers. build and write more secure code. I know as a developer and as a security person, one of the biggest fears we all have is that

Speaker 1: innocent people, people in general, are will get hurt. Because of our code. We don't intend that to happen. And unfortunately, there are parasites, attackers in the world that that prey on the weak, and unfortunately sometimes are able to take advantage of our code. So we should create a very basic checklist of every part of the framework of when you're writing, when you're using this part of the framework, what do you have to be worried about? And it should be really easy to use and just appeal to the community to help. And if you'd like some reading material. At Madasana, we always recommend the WA, we call it, the Web Application Hackers Handbook 2, the second edition, the first one

Speaker 1: is good, but the second edition is better. The Tangled Web, The Art of a Software Security Assessment, and Microsoft also has a great book called Writing Secure Code. And Microsoft's got some good books out there. And all these books will give you the mindset, the proper mindset to building more secure code. Now that's good. Well. Nice. I've got time for questions. Put the other slide back up the yeah. Sure. I'm gonna put these slides on my website. Uh so But well yes, the question part.

Speaker 2: Thank you so much, Lavey. I think uh it looks like you've left a full 19 minutes for questions if my arithmetic serves. Uh so please uh this is obviously an exciting questi opportunity to engage uh on security matters. Looks like we already have our first question ready. I

Speaker 3: just have a question about um you mentioned uh Taking advantage of safety of numbers. Uh do you believe that there's any sort of diminishing returns there Inasmuch as while you may get the benefit as a developer uh of the collective knowledge of of the community uh so that they can secure help you secure against attacks. Um Does that not also, though, open up uh doors for when there is a security exploit, that the payload is larger, right? If every Django project is using the same um uh code to secure themselves. Once an exploit's discovered, you have a huge swath of projects that you can exploit.

Speaker 1: So it does. I mean think about it in simple forms, heartbleed affected. Billions.

Speaker 3: That's exactly what I was saying.

Speaker 1: Right? And OpenSSL is a very popular library. But at the same time, it's better than the alternative. This is part of the security. You gotta kind of pick your battles. It is better than the alternative. Writing your own is not gonna get it it will not be more secure. There are very few people in the world that are able to put out solid cryptographic libraries. And for them to be initially secure by default. And I don't know them. There are people that do, but no one trusts them. And things that are built by the community have got a large set of eyes on them. Yes, well you if there is an exploit, many people will be affected. But at the same time, every time that there is a hole in them, you know that there's so much security review that has been done that they found a slight chink in the armor.

Speaker 1: And everyone knows about it, so everyone talks about patching it right away. It's not that everyone ignores it or it's known only to a few people, and then you don't know to patch it, and then you get hit by it six months later

Speaker 3: Thanks.

Speaker 1: You're welcome. Do should I repeat the questions or they got they have them good on the video? Oh, okay.

Speaker 4: So uh I have a more specific question. I'm sure other people have run into this too. So what's the best way to um encrypt a field in a a Django model. So so say I I wanna I have a uh you know user and I want to encrypt their first and last name. It doesn't there doesn't seem to be a very clear way to do this. Is there anything you would recommend besides the instinct of just hashing that back

Speaker 1: Well hashing it won't help you because the hash is supposed to be a one-way function. You're not supposed to be able to pull data out of it. Using keys are to encrypt it is really helpful. You can encrypt it and then pull it back uh and and then decrypt it every time you pull it out. Uh I believe Django encrypted fields don't hold me to it you have to check them out but uh Django encrypted fields uses Keysar and Django encrypted fields has an example has has a text a text-based encrypted field.

Speaker 4: Oh okay. Great. Thank you.

Speaker 1: It's not an endorsement to Django crypto fields. It's I I I've looked at them once, they may have changed, but check it out.

Speaker 4: something like that.

Speaker 1: Yeah, it's a it's a it's a third party application.

Speaker 4: Okay. Thanks.

Speaker 1: You're welcome.

Speaker 5: I also have a Django specific question. Can you comment on development versus production settings? Um example that comes to mind is allowed hosts.

Speaker 1: Sure. So most important, debug mode must be turned off. Now you you may all laugh, right? And and and I did when I was a Django developer, and then I joined the security world and I was like, okay. Now I'm going to count the amount of sites I've seen debug mode turned off. Right? Almost every application that I've tested had debug mode enabled in some way. And It's really, really important for that. Now, also in production, you're dealing with things like rate limiting and abuse that you're not used to. And it's really important to look at your every use case is different. And Just set some really basic rules and guidelines to how much of your service your user should be using.

Speaker 6: I have a quick question that might be a little too specific, but you do you have time to elaborate a little bit on the sort of spoofing the post by using a get and bypassing the C SERF and how safe is it to trust um in if you're using a function-based view whether the request is a post? or not.

Speaker 1: Sure. Sure. So uh I'm gonna talk in the abstract and then I don't have any code to show, but uh I'll try to be as specific as possible. So every function-based view takes a request. It'll take any type of HTTP request, it doesn't matter. Now, within the code of that function are specific directives to process based on that request. If request. post. So if this is a post request, process the form. If request. get. do the opposite, etc. Now the the issue I was describing was an issue that has been found where a view existed and this view

Speaker 1: used request. meta. So it wasn't just looking for a guest, a get or a post, whereas but the developer assumed the fact that it was in a form that it would be posted to, but it can easily have been requested by a get. And that was the issue.

Speaker 7: You mentioned during talk that it's important if you do venture down the security road and writing your own software for that. your own controls. It's important to understand all the attacks that you know you're going to have to you're you may encounter and anticipate. Handbook. My question more pertains to is do you think it's valuable to be able to understand and execute some of these exploits yourself in that process?

Speaker 1: That that that depends largely on the way a person works and learns, but for in from my perspective, I learned software security. by looking at the framework or looking at the Django framework and just seeing what does it do? How does it work? And then looking at other implementations and saying, why are they different? And then comparing the differences and understanding how it can be attacked. Some people find it really helpful to actually attack. And for that there's Uh OWASP has a program called WebGOAT that allows you to a really vulnerable web application that allows you to really test out the application to test that application security. The Web Application Hackers Handbook will give you a lot of those attacks practically. They make use of a uh

Speaker 1: proxy tool, web application proxy, called the Burp Burp Suite. And it for for me that's my Swiss Army knife when it comes to pen testing. And I I really rely on it heavily for everything that I do. And I think that going through specific components, understand and just reading about the attack surfaces on those components will be really helpful. But it whatever works. If if it's easier for you to to break into the the actual application, there you have it. And if it's you know it's easier for you to just look at secure implementations then if it's easier for you to do both then do both Thank you.

Speaker 8: Hello. Um, my question is about do you have a guideline to know when it's appropriate to step back and ask well not ask but when when doing security it's holistic so how can you know whether the Django layer is the appropriate layer to address a certain security concern. With you know a stack with other layers in it.

Speaker 1: So uh just to to expand a little bit on what you just said. Why should so let's for example in building a rate limiting control, you can build it, let's say you use Nginx. You can put that directive in Nginx, you can put that directive in Django. Why should you do one over the other? Now It really depends what you're looking for. Nginx knows how to proxy and serve files very well, right? So when you want to limit the amount of IPs that hit your site, You can do that in Nginx. When you want to limit the amount of IPs that hit your s that hit a specific endpoint, you could do that within Nginx. However, it doesn't know anything about your application. Within Django, you can build rate limiters that can rate limit specific actions so that should an attacker decide to abuse that specific action, you can throttle that entire action across your application.

Speaker 1: It's not bound to a URL as Nginx is going to expect. It's bound to a set of behaviors. So it's largely dependent on what you what you want to like the type of control you want to build. Both are really important. In fact, I'll say everything that you can get out of Django, as in put into Engine X for rate limiting, should be done before that, because why start to get into the request-response cycle? when you you can just stop the attack from ever happening. Yeah. Uh

Speaker 7: Django has a lot of settings around cookies, like uh HP only, secure, sign cookies. Do you have a a recommendation of how you set up your settings? Or do you just use the defaults or

Speaker 1: So well it really depends on the site that you plan on hosting. For example, if your site is not hosted under SSL, then sending the secure flag in your cookies is kind of going to break the whole HTTP sessions. So uh generally when when I set my my the when talking about cookie settings I make sure that HTT only is set on both the session cookie as well as the CSurf cookie, and then secure, I like to host fully over SSL. So secure on both of those as well. Now what's important that most people don't know is that the CSERF failure view exists by default and is one of the easiest ways to profile if a site isn't is is actually a Django site. Send a post with a Either a missing C-surf token or an invalid one, and you'll get back the C Surf error view.

Speaker 1: And it'll also tell you whether the site's in debug mode or not. Now That's it can be problematic. Most people don't change it. It's really simple too Anybody else? Yep, yep.

Speaker 5: So my question is more about Python 3 and tools like Kizar and encrypted fields. Is there anybody working on that? Or any Kickstarters? Are you seeing any new tools coming out that support Python 3 versus what you're talking about earlier?

Speaker 1: Yeah. So uh I'm gonna expand your question to also PyPy. Right? Kizar makes use of I think it's uh Python PyCrypto. PyCrypto is a C extension to Python. Uh PyPy doesn't work on PyPy, it doesn't work on On Python 3. And the the reason I chose Kizar is because Kizar is a set of executables. It's also it's written in Java, you can download the executables written in Java and run them. Now, y'all, what is important is that you don't run these executables and open yourself up to command injection. But largely you can make use of those executables. Use a tool. Don't use a like it don't use it so much as a library.

Speaker 1: And that way you're n you're abstracted away from the internals of it. and you're just simply using like is as if you would use cow say on in shell, you're using just a shell command. You get you you put in data, you get out, you get back data, it's that simple. Any more?

Speaker 2: Uh uh Lady, it seems like a lot of um uh yeah, I I I respect that you're sort of instead of talking about attacks, you're talking about best practices. Uh Against surfaces generally. But it seems like the surface you're talking about by and large is uh the request response cycle For example, you say, let's put all authorization in one place. But what about for async? What about if you're dispatching uh broadcast and you're not exactly, you know, you need to understand who's on the other end. Um And I I f I find that that logic sometimes is wanting for a home and uh it seems like probably it's not URLs. py. So what do you do with that stuff?

Speaker 1: So this is why I chose the request response cycle, because I don't think forty-five minutes or two hours would have helped with async security. What when it comes to security, it's when it comes to protecting yourself from vulnerabilities, as I mentioned previously, you largely have to assert what is going to happen. You have to be very specific. And you have to really Push yourself to understand what's going to happen. When it comes to asynchronous programming, things are largely being handed off to different, let's say you're using coroutines or or now event-driven asynchronous programming. You can Throw yourself down a rabbit hole really fast. I mean, how many people want to think about race conditions and asynchronous programming? Well, every bank that exists today does not make use of asynchronous programming when it comes to transferring money.

Speaker 1: For the the the fear of race conditions. And even within race conditions, they make sure that everything is within a transaction. Uh when when when you mention asynchronous programming, from my perspective, I'll look at it from the Python way of not just API calls that are being sent out to the to the server. Because those are also handled by Django's request response cycle. Whereas with Django itself asynchronously processing certain things. One important thing to note when dealing with it, and just and I'm not gonna dive really deep into it, is just because it's async doesn't mean it's lightweight. And just because it's lightweight in one place doesn't mean it's lightweight in the other. For example If you manage to find a view that you could really increase the amount of processing

Speaker 1: power that is required by that view seeing They're they're based on let's say one of the most recent holes within Django is submitting us within a multi-part res uh multi-part request. a set of files that will cause Django to do to perform an ON operation. If you can find that within an async piece of code and they're using GEvent. then that person's got real problems because Gevent is great when it comes to I. O. and it actually isn't so good when it comes to serious CPU handling and it's going to stop responding to everything else. So, what's really important is that you rate limit as much as possible. Don't assert don't think that you can upload a 300-megabyte file and it will be really easy on your system.

Speaker 1: The second thing is to remove the asynchronous parts of your code from where it can get a little bit hairy. And what I mean by that is. When you have code that is going to run, say payment system, you want to make sure that that payment system, that payment happens once and only in one location, and can't be triggered. Multiple times within a specific set of set of time. So in the regular world, you'd use locks, right? You'd lock the start of that payment, you'd move through the code. And you'd end the lock. However, uh Python's cooperative scheduler may give especially asynchronous programming may break those locks or maybe get you to the point where you may be within multiple locks at the same time

Speaker 1: do do certain things. So it's important to know when to be synchronous. That said, it does mitigate a decent amount of denial of service vulnerabilities, so your mileage may vary. Anybody else? Yeah. So uh I'm

Speaker 7: I'm an I'm an educator and teach people uh Python programming, Python web programming and so on and so forth. And one of the most difficult areas for me as an educator is that I I tend to be a fairly trusting programmer, which makes me very bad at this kind of work. Do you have any advice for educators or for students who are learning this kind of thing about ways to make themselves constructively paranoid?

Speaker 1: Well, uh first of all, being a trusting person is it it's great. It's be hum you know, unfortunately we're we're not a we're not as trusting as we could be, but Um let's uh let's just as a show of hands, how many people have invited people over to their homes? Okay, the people that didn't answer are definitely That's a little scary. How many of you how many of you guys have known that person before you invited them over to your house? Okay. Most. How many of you have not known that person? Excluding Airbnb? Oh, one person. Okay, good. Right? So you invite someone over to your house, you know, you see someone walking over the street and say, hey, you look hungry, come in for a meal. Right? Now you're going to expect that individual to be courteous and to know their boundaries, right?

Speaker 1: You know, not to put the silverware in their pocket, not to, you know harass the other members at the table, etc. And largely they, you know, very nice individuals, they will they will be like that. But when that person oversteps their boundaries, at that point you show you kindly show them the door, right? Now, when it comes to building software, we don't always have that luxury of being able to handle just one request and ensure that everything is working nicely around it. So we try to assert as much as possible, place all the rules around that one request, that guest in our house, and say, these are the roped-off areas. You can only go into the bedroom if you're a member of the family. You know, okay, everyone can wash dishes.

Speaker 1: Uh but uh you can only do certain things. You can only turn on the TV if you're a trusted set, you know, you're you're a staff member, you're a member of the family. You can only change the channel if you're old enough, if if if if you're older than let's say 18, right, or 16. Now That is is kind of how you have to look at your users within your application. You're going to have the majority of your users are going to be good, hardworking people. Hardworking, sorry about that. They're gonna be good, well-minded individuals, but you're gonna have that 1% that's going to literally just probe you to find your weaknesses and being assertive from the onset Is really important. Now,

Speaker 1: the assertive part of security actually comes to me from a different part of my life, as you may have realized. I'm a religious Jew, and uh Judaism is a set of laws Those laws are largely written in many places but are collected in a book called the Talmud. Now, I I don't think many of you have learned the Talmud here, but the way every law in the Talmud works is that you take we They discuss the law. They say, we know this is supposed to happen, or we know this is the law. Now let's look at the limitations of it. And they hypothesize everything. And they, from a very rough piece of stone, which will be the original law, they sculpt a masterpiece of every single facet. when it should be done and why it

Speaker 1: it should be this way. And this is I I've taken that part of my life and built it into writing software and writing secure software in where all the code that I put out, I'm very explicit what should happen and why should it happen. And I don't look at kind of the okay I hope it's all gonna work. I kind of I I'm I'm not it's not that I'm not trusting of my users, but I'm just assertive and I say you are only a user if you meet these requirements. The same way if someone walks into your house, they are only an invited guest. If they can accept common courtesy. No more questions? Nice.

Speaker 1: Thank you so much.