 involved with all the security releases for Drupal 6 and through the years I got to see all the common problems in the That we deal with in the Drupal security team So I hope I can help you in avoiding those and to be able to tailor this session for your needs I hope to see how many managers there are in the community are in the audience. How many of you think you are managers? Quite a few. Okay. How many of you think you're a site builders? Very good. That's that's the track we are on. How many of you think you're a themeers building themes for Drupal? That's not much. That's kind of interesting. How many of you are hardcore developers or not so hardcore about developers? Okay, that's very good. So I hope to have content for all of you And if the only thing that you gather from this session is to go and buy this book Then my mission is accomplished It's not written by myself. So it's not a shameless blog on my own It's written by Greg Nattison. It's called cracking Drupal drop in a bucket and it's a very good book for learning about Drupal Security it's for Drupal 6. It's not for Drupal 7 yet as far as I've heard it's being updated for Drupal 7 It's very good to learn the different problems and especially if nothing else you read I think chapter 8 Where it talks about finding Drupal sites to hack into how you hack into Drupal sites Different techniques and then how you prevent those. It's very insightful and you learn a lot about how How how you can look as a third third party on your websites and see it see it from a distance and Find these problems Of course you think you're probably affected and you need to know about this But a lot of people ask this am I really affected? I'm like I'm running a small block here or a small e-commerce shop and nobody's interested really in the data that I have here and The answer to this one actually is that people look for all kinds of data on the internet If they can hack into your site and you are a mini skew small site somewhere on the internet They might still be able to get get your use get your user account database and be able to use the same user accounts on Facebook or on Twitter or somewhere else where it's more valuable or hacking to someone's Apple ID or Amazon.com account because many people use their use same credentials on all kinds of websites So even if your site is just a small a bit in the ocean somewhere You can easily have valuable data for people to get Even if it's just data on other people and The other reason that you might be concerned is that with very simple holes Your administrator user can be taken over and that means anything can be done with your website And it's pretty serious and I will show a few ways to do that on a Drupal site if it's not If it's not operated properly Now I chose to use a framework for this session that's based on the open web application security project top 10 security top 10 Risk list right so they looked at all the risks that websites are Facing on the internet and put up a top 10 list of what are the most important ones and what we should take into account first and foremost and I'm trying to put the Drupal security practices into this framework. So you have a I have a common framework to compare the Drupal solutions to and Kind of relate to what the industry thinks about these problems I Did not put all the things in order because I think the the most important for us here to start off is number six Which is security mis-configuration because it's very easy to go wrong in that area Anybody heard of the word press comm attack that happened in mid-April anybody No It's kind of interesting. That was a big issue. I'm not picking on word press calm because it's our competitor No, this could just as easily happen to any Drupal site. It's not work press Pacific the the problem the the reason that I Come with this is because it was a huge scale problem with I think 20 million websites that are hosted there. So What they've experienced is that they've had a perfectly nicely set up word press instance and the attackers Went in below word press on lower levels and gain root access on the servers And they've and they got access to the source code of all the custom source code That's not open from word press calm and some of the customer data that was there and took that and did something with it We don't know we don't know what it we didn't get a lot of information on what actually happened there What we got is that it wasn't attack of the system under word press it was attack outside of word presses control and When you're thinking about Drupal security, it's very important that whatever you do with Drupal Drupal lives in a huge system So there's a lot of things running around Drupal that you have on your server and you need to take care about that first It matters it matters a lot what kind of tools you use to maintain and deploy your website I would say you should avoid FTP at all costs anything that sends unencrypted information over the wire You should avoid Well get it get to the fact later that all of you who have your open laptops might be sharing some valuable information about Your account, but we'll see that Check your client to whatever client who you use where it stores the data if you search on Google for for Total commander or Windows commander FTP Password tool Then you'll find tools that you can just upload a total commander password file and it will Decrypt it for you and you will have access to all the passwords that are stored in that file You can just upload your password file online So anybody who who has access to your machine like a virus cracking in can get all your Credentials to all the sites that you're using with with total commander Think about who do you share your server with if you're running on a shared shared hosting service who else is Putting software on that service who else is putting all kinds of other tools on that service and think about what they Have on there. Are you confident in who else you're sharing servers with at one time? I've had my my personal website at that at a At a shared hosting provider and turned out I was running with some hard line leftist parties Like political parties I was running on the same server and I was kind of concerned that if somebody would like to attack them What happens to my data? So think about that if you're running other apps that could be pretty Pretty problematic There's a forum software out there like PHP BB to that's historically very vulnerable to security issues So even if you perfectly secure a Drupal website everything is perfect on your Drupal website There can be other tools that can can be used to hack into your web presense of course If you can go even lower the OS layer PHP your SQL server your keys to the server room, whatever But when it comes to securing Drupal There's some very basic configuration things that you should think about Drupal tries to help you pick a good admin password Drupal 6 doesn't do a very good job in that it like throws big red And yellow error messages every time you don't type the ideal password in the world So admin is not a best password Keep in mind the suggestions provided by Drupal, but there's maybe better better Suggestions around the internet of picking strong passwords Look at all the admin permissions on the site if you give any of those out to anybody Your site can be easily taken over if you have administer users or administer permissions Permission given out to somebody they can edit other users And grant them new permissions and then those users can take over your website. So a lot of these permissions are Opening up your system very wide to anybody who Who wants to crack your that are your service? So think very wisely about who you trust those administer filters is permission that looks very very Safe it's like yeah, it's filters getting in data and then putting out HTML And we'll see an example soon that if you Pick this permission for some user They can also take over your whole site because it's content coming in your service and administer filters about what kind of security Process is put on that content to be printed to the user and that That control can let people take over your website as well There is so the security team is hard at work in putting out fixes for all the modules that are on Drupal There's thousands of modules and there's a lot of work in and putting that out so if you want to Maintain or not if you want to but you shouldn't maintain your Drupal website to be up to date with all the security updates and Drupal has the built-in update module for that which you can enable and it can alert you by email about latest updates to your modules So it's very easy to do. I would suggest you do that And the other thing to note here is that for those for those new versions that are coming out We have a standard to do those on Wednesdays the reason for that is So we have a predictable schedule for all the important security Updates that you need to make to your website. We've put those out on Wednesdays So if there's no security releases for your models on Wednesdays You can go on holiday on the Thursday and come back on a Tuesday We let you go to the beach and sip mojitos But on Wednesdays at any module can have a security release also It lets you have some Q8 time with your website until you need to leave for the weekend, of course So we have a process in place for informing you and we have a process in place for making the releases predictable Further on securing the Drupal configuration itself, I would say you should avoid any kind of PHP input Drupal has this PHP model. You should forget about it. It's not there never enable it if you want to Hide it without hacking Drupal core. You can use the paranoia module That hide hides the PHP module among other very good things and never allows you to enable it It also hides itself so people cannot disable paranoia module And also there's all kinds of other things to improve security on your website So I think it's a very worthy module to to look into using as I've said you should watch your input formats One of the great things or one of the interesting things about input formats is that they come with standard help text So when you enable some input formats, they come with standard text like this This field allows you to enter any kind of HTML input or these tags are allowed and it lists all the tags Now this these very standard text can be Google then we can search for sites that are vulnerable to certain Injections of data so we can look for the standard tags and Find websites that we can enter malicious data into and and hack into so if you if you enable Fully HTML input for example for anonymous users, then you can easily run into Problems where people Google your site and then enter data and they already had your property There's the security review module which runs Runs through these things that I've said most of these things that I've said and many more that help you Have a good check of whether your sites configured securely or not These are some of the Rules that you should follow now to go back to the first first point in the OWASP list It's about injection. There's many kinds of injections and in the web security I'll talk primarily about SQL injection here and hopefully get you a comfortable feel of how Drupal tries to protect you from that SQL injection is very simple. You have you have your web address and there's some data coming in there and if somebody puts in a Number there it means that it updates your value to that number but if somebody puts in malicious data there like They end the quote and then they do something to update the user password in that table or They do a select another table or do an update on another table. That could be pretty dangerous So what we do in Drupal is we protect that or we force that kind of data to be of certain type and That type in case of Drupal 7 is introspective from the database schema So we look at the database key, man We realize that that value should be a number and be converted that value to a number at that place and we ensure that there is no unintended data to go in there if You need to have your dynamic table names either in your modules or in your themes to be Protected in this way look at DB escape table function. So the injection Problem that I I just explained is basically about data coming in right from the web request and Right into in this case an SQL query and running through there But the same can happen to any kind of data that comes from another database table or an XML file or an RSS feed So just don't assume that the data is coming always from the URL Important part is to always treat the data. That's coming from somewhere that you don't trust as potentially an attack and To add the place where you use the data ensure that you use the right format now as I've said I have a few code examples in my session and one of the points that the that the Drupal security book makes is that most of the vulnerabilities on Drupal sites are in themes Okay, so people download modules and those modules are pretty well Controlled and we put out security releases for those modules But themes are custom made for your Drupal websites and most of the problems come come from themes So even if you even if you think you you are just building themes It might be the most dangerous thing to do for a site security A much more interesting is number two is cross-site scripting a abbreviated XSS because CSS was already taken Is a very similar problem, but this time we are not injecting data to an SQL query We are injecting data to the HTML output That data can come from the query can come from the request the URL either a form or a query string or somewhere else And we are just bringing it out or it can come from data we stored previously Like the node title Drupal store Drupal usually usually stores data without any filtering on it So we store the data and when you use the data in your theme in your module in your view in your whatever You're responsible for sanitizing that data and making it secure Okay, so the node title can contain any kind of data that breaks your site or makes your site vulnerable If you just put the node title in the output print out the node title as is in here in the theme Then it's going to be vulnerable so we made a lot of things accessible in themes and in pre-processed functions that are already secured like the dollar title Variable which is already made secure, but if you're going deep in structures like the node title property that is insecure giving full HTML access or trusting people to enter unsafe tags is a similar problem and cross-site scripting might not look like a Big problem at first is just injecting stuff to your web page. How can that be serious? Why it had security put out a research paper. I think that was this March, yes, and they estimated the the likelihood of cross-site scripting on any website as 64% so that your website has a cross-site scripting issue you have 64% chance Okay, so your your website likely has a cross-site scripting problem now if your website has a cross-site scripting problem like printing out the node title or You're granting full HTML access to people who cannot be trusted or those people can enter unsafe HTML tags or you grant Administered users permission or administer filters permission to people who done who shouldn't have that then those people can do this to your site So this is a code sample that that was posted by Heine Dostra the Drupal security team lead way back and This exact code sample runs on Drupal 5, but the same code same principles can be brought forward to Drupal 6 It's it's more code But the same principles run on Drupal 6 and a bit more work is required for Drupal 7 But but a cross-site scripting issue on any Drupal 7 site is enough to achieve the same effect So what happens here is that we put in a little just a little bit of JavaScript This is not much right. This is a tiny code snippet what we do is We get the user slash one slash edit page, which has the edit page for user number one And when that actually happens we run this function If it's a successful request Then we look at the form token that ensures for Drupal that we loaded the form We remember that form token in the token variable and we in the payload we put in that We are the user edit form We put in the token and we put in a password of our choosing and Then we submit the form with a post request. That's it. Okay So if you if you allow people to enter full html or if at any place in your theme You output a node buddy field without filtering or a note title filled without filtering or other kind of data That comes in from the request or is stored in the Drupal database People can enter this or equivalent source code and can hack your user one password And from there they can do anything. It's they own the Drupal website If they can enable the PHP model from there, then they can run code on your web server However, they want. Okay So how to protect from that there's a lot of Functions in Drupal that help with that and this is the main family of functions That you can use in your theme in your module in your custom PHP snippet in your views header PHP snippet, whatever so we assume HTML output here and If you encounter a URL that's to be output then we have the check URL function if it's not a URL but a but plain text like a note title or I don't know an email address Then it should be run through check plain if it has a format attached like a node buddy Or in the other place in Drupal where a format is attached to the text Then it's check markup and you should provide the format that should be used and if there is no format attached Which I which is at some places in Drupal like the site mission statement or site mission statement in Drupal 6 or the I Don't know so quite a few places in Drupal core like like aggregator category descriptions stuff like that Then you should use filter accesses, which still does some cross-site scripting filtering If it's none of these and you trust it Then you then you can output to HTML So we do these preparations to a theme variables in the theming flow in Pre-process functions, so when you look at a tpl.php file in your Drupal instance That that will have a huge list of variables that are already Pre-sanitized for you to be used in your theme So I would suggest you to use those first and foremost And if you really need to have custom data in your themes in your modules then look at look at these functions We also support this With our localization infrastructure, so we have the tn format plural functions which automate calling off check plane and And the placeholder theming functions So you can use the translation function to compose a text snippet That has these kind of this kind of filtering in there And it still reads like name has a blog at URL and the URL is filled in proper and the name is filled in proper Same is available in HTML in the JavaScript for triple dot tn triple dot format plural But not all output is HTML. So this as I have explained was all the ways to filter text for HTML presentation, but you will also do stuff like sending emails or Building data for other Output formats you should always consider the escaping for those places like for sending html depends on whether you send html email Or plain text if you send plain text the module has a function to strip all the text from the html and format it Sensibly for sending it an email So think about the kind of input you have whether it's already sanitized if it's not sanitized Think about the type of Format that it has and then apply the sanitization Appropriate for the output format that we assumed to be html before but can be any other format as well Number three is authentication and sessions It's basically about weak password storage and account management or session hijacking Or lack of session timeout and Drupal already has pretty well Pretty well crooked solution for this. So you don't need to care a lot about this problem We do store passwords hashed and we are increasing our security with every release. So Drupal 7 increased on this from Drupal 6 We do change session IDs when people are Locked in or locked out when permissions change actually in fact when permissions are heightened So whenever you have you whenever you get new permission we change your session ID So we can avoid you being trapped in a session hijacking problem We do work on top of SSL and we do have some support for SSL that we'll see later And we do have some nice modules for that which we'll also say later Number four was insecure direct object references and that's again very simple for Drupal actually It's looks like a similar code example I've had for injection but in this case what happens is that I'm putting in the number and I'm just getting data for That kind of value and I'm not checking whether the user has permission to have access to that value And there's a lot of thinking to go in there When you're building a Drupal site so our menu system That's our main system for dispatching requests in the Drupal system is built for is built with checking for permissions It's kind of nice if you do want to check for permissions yourself I would suggest the user access function if you do want to check a note permission There's specific functions for that and if you're writing queries directly against tables, which I suggest against But if you still want to do it then you can add the Node access tag to it now one of the one of the very interesting things here and one that many people miss Is that when you create a view? It does not filter for published notes Automatically out of the box so one of the things that many people miss is then they create a view They put out their content and it will list unpublished notes at first and then you need to go in and check to not list the unpublished notes that's kind of a Insecure object reference we we list all those contents and some of them is not available for you although you can see it One of the more interesting problems is cross-site request forgery That's called cross-site, but it can actually happen on your site So one of the things that you can do with the Drupal user Is lock them out So if you can post an image or something that can make a request on behalf of the user on a website You can lock that user out So if you post this code on on a Drupal site that allows for images and anybody was this visit this page They will be locked out Okay, this is not very interesting because you know you're not gonna gain anything by logging them out But this is the type of problem that That cross-site request forgery is about is that we are forging a request on behalf of the visiting user With for example an image there's other ways other tags in html that allows this like the script style tag other tags So the real problem here is that this can be an action that's destructive for the site like deleting something So if delete if we if we refer to deleting something and it actually runs without questioning you Are you sure then it's going to be a problem for cross-site request forgery So if you are fed up with Drupal always asking you about are you sure you want to delete this? Then it's because of this problem if Drupal wouldn't ask you then anybody would be able to delete stuff on your behalf Okay There was a big problem with this when Google released their I think browser speed Plugin for firefax back in the day way before they released Chrome How many any of you remember that the firefax speed plugin? Yeah So the problem there was that the Google preloaded pages for you like you visited a page and all the links it preloaded for you So when you click it, it's going to be available right away Now if you're on a note page like the note admin page delete delete delete delete, oops, that would be a problem so So this is a this is a problem for anything that does not check or does not ask Whether it whether you actually wanted to do it and just does right away some models do this So there's some quick voting modules in Drupal where you just click something and it happens And those might be vulnerable to hacking this way And then you need to decide whether you want to have a quick voting system or less gameable voting system So the Drupal approach to solve this is that we we work with a post submissions by default Which makes it harder to do this kind of work We include tokens in the form so people need to download the form first That includes a token and when when you submit the form you need to submit the token with it as well We check validity for that and we do provide APIs for those who want to have one click links that have tokens So it is somewhat harder to break, but if you have a cross-site Scripting problem then none of these will help you none Number seven is insecure cryptographic storage, which can happen with your custom data But Drupal does do a good job of handling this for all the data that it handles itself So as I've said before we use a one-way hashes to store passwords so they cannot be Correct as easily backwards We do provide a randomly generated private key on every website That is secret in your variables table to use for custom encryption and we do have a quite a few modules for you to encrypt data and I Don't have a concrete suggestion on their what modules to use there's multiples depending on your needs But a lot of people are making backups at places. I've seen people sending backups by email to themselves and yeah, and And if you don't ensure that those backups are safe those backups cannot be copied then whatever we do on on your database It's not going to help so So be sure to look at your backups and who can access those backups because that can easily be a problem as well This is the environment around Drupal that we don't often think about but is very important Number eight is failure to restrict your access. We sort of touched on this before Our menu system handles that It's your responsibility to configure the permissions on your Drupal website to be proper and The security team has a guide on this that I will link to later And it's your responsibility to configure your views proper to Not least unpublished data number nine is insufficient transport protection and At this point I would like to ask Who heard of fire sheep? Some of you okay, so fire sheep is a very nice tool So any of you who have your laptop open can go and download fire sheep It's a free Firefox sidebar plugin that you can download to your machine And what it does is that you turn it on and It collects or it looks at data happening in this open network So anything that's happening on an open network or now actually we do don't have an open network here, right? So if you walk into a bar that has an open network and you just flip up your laptop with fire sheep on it You can look at the data that's flowing on the open network And what fire sheep does is it makes very simple for you to? Capture meaningful parts of that data so it looks at that data and it searches for website login information for example so if can't find the Facebook credentials for for the person that's sitting next to you or At the other end of the bar and it will actually I will even show the Facebook profile picture of the guy So you click on that and it opens a browser for you that is logged into that guys Facebook profile Okay, and you can do whatever in the name of that guy and The reason for that is and and the reason for that is two-fold one is that the network is open That is a very good sign is that they are not asking for a password and The second reason is if that Facebook profile was access on the HTTP connection. That's not encrypted So if the network is open and the and the data itself is not encrypted Then you can actually break into that connection and then grab the user session ID and from there You can do whatever in the name of that user That's pretty powerful so When you go to a bar, you should ensure that it either has good Protection for the wireless that you're running with or you have like a VPN to connect to before you do anything And on your Drupal site what you can do is that you can try and run your Drupal site on full SSL Which is expensive But it's it's being introduced in most of these high-profile websites for this reason because Breaking into these accounts is as simpler by the day Or what you can do is to try and secure some of your web pages Like what we do on on Drupal guidance comm is that we're running with a set of these models To secure the login process itself and then secure whatever action you want to do on your account So that those actions are protected from the outside so secure pages is for Setting some of your web pages to be forced to run only on SSL So like your user login or user edit pages would only run on SSL and secure pages prevent hijack is about Trying to hide trying to prevent hijacking that session cookie that you get when you log in Which becomes unsecure when you visit the other pages on the site? And this sets a secure cookie additionally to the insecure cookie and ensures that you can only browse the site if you have both There's a very good example of setting up these models in a good Constellation on the Drupal Scout comm website and I would suggest you it's very easily findable with the When you navigate to the knowledge base So you don't need to write all that down and and these videos will be available and my session slides will be available So it should be good. It's also important to not just secure your website But also use a valid certificate if people are used to your website downloading and spitting out an error message that the certificate is invalid then if somebody Performs a middle a man in the middle attack and replaces your certificate and presents a different website But in your in your website's place Then they will not notice if your site is always popping up an error message of an invalid or expired or a Self-signed or whatever certificate. Okay, so make sure that you have a valid certificate on any website that you value And finally number ten is kind of interesting the last time I've had this session Drupal still had vulnerabilities in Syria And I was kind of trying to go it low The invalidated redirects problem is that you have a link that looks like it goes to example calm But it actually redirects to evil calm and I can put anything at the end of the URL and it would be direct there So Drupal used to have this problem. I think a year ago or so and the approach that it now has is Is that it tries to use local paths? So none of the external you none of the redirections build external URLs to redirect to and it also has validation in Drupal go-to that that looks at your looks at your Redirection and whether that's an interview or not, but All your custom code or your themes that do like work flow simplification on your site can be vulnerable to this problem So look at what kind of input you allow there and filter for For relative URLs if at all possible. So this was the OWASP top 10 list as it applies to Drupal I hope it was helpful and I'd like to touch on one more subject here Which is a very common question Whether he's open source secure, of course, I'm saying it's secure. I'm from the security team I'm working with the security team for four years. So of course, I wouldn't say Drupal isn't secure Because open source makes people look at it open source makes people We use the same code all over again and they find mistakes and they send it in and even if they post blockposts about it And they come and it goes out to the wild. Well, we'll be able to figure it out and fix it and release it So a lot of a lot of ice we have on that And also there is always more smart people to look at stuff I'm not at all good at all the ten areas. I've listed. No, I Have expertise in a few and I know what to look for but when I have a problem I have guides to look at I have people to talk to I have I have the security team to report errors and They help with fixing them. Of course open source is insecure because people can find holes in there and people did Did go into publishing blockposts about the holes before we could fix them that happens That's kind of the the The trade-off that we have here And also to fix becomes public and it becomes available and then people can look at how how sites that are outdated can be attacked And the Drupal security books chapter 8 talks about some of those problems that oh We've had these previous security problems and how you can find those sites and how you can break into them So so this is somewhat of a problem. It's not It's not really your issue if you follow the security releases and you patch your sites And if you keep yourself well educated on these security problems So in concrete Is Drupal secure or is it not secure? Of course, we try to design Drupal to be secure I've had a lot of examples here on how we have apis to filter text how we have apis to Validate form submissions how we have apis to validate tokens for encrypting data for doing a lot of cool stuff So so we build these tools to be secure But it's always on you to use it in a proper way So if you give out full html or if you give out administer users Or if you leave a sticky note on your monitor with your password then we can't help you out There is a guide to writing secure code that I suggest everybody read who ever touches code even Even if you think it's just a theme template file It's the same php environment that the theme template files run in then the rest of Drupal. So please look at that And be mindful of all the all the ways that you can make your Drupal site secure What we do for you to be to feel secure and to be secure is that we built a security team That is entirely built out of volunteers That we ensure to To put out security releases and who try to educate people around here to be better at security So our three goals as to this is to help design Drupal to be secure by default To help educate people like you so that's part of what I'm here and the third goal is to fix problems That's the third one. That's the last one. So we try to design Drupal to be secure To help design Drupal to be secure we try to educate you to use it that way and if there's a problem we help fix it our duty is that we look at Drupal core and all contributed modules on Drupal.org which Means that we look at stable releases of modules So if you're using a development release or an alpha release, you might be out of luck So be sure to look at the the stability level of modules. We consider Stable releases to be supported We do not actively look for vulnerabilities in contributing models We we are a middleman between the reports coming in and helping the maintainers put out releases So we we look at we assess the vulnerability that's coming in we contact the maintainer and we work with the reporter and the maintainer to put out the release for For the module or the theme in question. We only support the current and the one earlier version So currently that's 7.x and 6.x. We do not support 5.x and when 8.x is released We're going to stop supporting 6.x We do have a few points of contact We do really we do announce releases at Drupal.org security We have a separate feed for core releases. We have a separate feed for contributed releases We do have a guide on how you can report issues On security.drupal.org. We do have a guide on how can you report correct sites? But it's very helpful if you can provide data to us on how we can reproduce the problem so we can actually fix it and There's a There's a discussion group on groups at Drupal.org called best practices in Drupal security That should be helpful if you have more detailed questions And finally let me once again suggest the cracking Drupal book. It's very good, especially chapter 8 So if you haven't yet gotten around to reading this book you should Any questions unless I'm out of time Yes So the question was if I know any issues with Drupal configuration like outputting errors on the screen Yes, outputting errors on the screen might help attackers to get information on what kind of environment your site is running at Like the the operating system the place your code is running or the SQL error message Provides information on the query that that data is going into so Outputting error messages publicly on the web page is not only scary for visitors to look at big red messages, but also Information disclosure you provide the information for the attacker to guide them on how they how can they crack your website? So I would consider that a dangerous Thing uses a very good regular development site, but I wouldn't suggest to do it on the life site Do I know anything else than that? I don't know it sounds like a too general question for me Yes DDoS attacks So the question was can I speak anything to denial of service or distributed denial of service attacks on any protection to that? It's pretty hard to it's pretty hard to To protect for that I must say of course your best protection is if you have a very well distributed system to run your website on and you can scale automatically up to any kind of Traffic, but it can be very expensive Drupal does have a very simple flood system that tries to Protect people from flooding like contact forms and that kind of stuff I would say that's not a deck that that quit for any sizable attack So I would suggest you look at the web hosting layer and look for denial of service attacks there I can connect you with the outrageous pen. My colleague who's working on solutions for data. Acrea I think he would have much more concrete information for you Yes yes, so the the suggestion was to Have your own inner security team in you To to look at the modules and the available code With a critical eye So we do say we support all contributed models on Drupal.org, but we do not make any guarantees that any of the modules would have a Backdoor or a security problem or a cross-scripting issue or whatever any of the models could have We cannot guarantee that so you should look at the activity of the module if it's being worked on by a lot of people If it's being used by a lot of sites if it has an active Comment history if it did have security releases before that's a good indication that it's a good Module if it had a lot of security releases before that's probably an indication It's a bed module But if it had a few it had eyes on it to to look at it and fix problems And the security team often looks at modules and finds other problems and then tries to fix multiples together not always but tries to Tries to do a a batch practice around that So there's a lot of these things that can inform you on Drupal.org and help you in your module selection when you Try to look for secure tools Yes, the question was if if the blowfish bug affected Drupal in any way security wise and I don't know the answer Unfortunately, sorry So the question was is it a problem that all of Drupal is in the document route Under your web server and is it isn't something that Drupal warns you about when you like upload something with FTP or like or FTP whatever you upload a new module to your site and you change permissions on that or something I Don't I don't think Drupal will warn you on changing the permission on the doc route or in the modules folder it will look at things like the settings file the files directory and those things and It is a it is something you should consider that Drupal runs in the doc route all together People can upload stuff there and Drupal tries its best to protect uploads and rename uploads to have different Extensions so the web server will not run them and there is and there is a Big issue for Drupal 8 to move most of the core stuff into its own directory So all the stuff that is modified by Drupal like the files and profiles and those things and custom modules are in a Separate place from the rest of Drupal core so you can keep the rest of Drupal core untouched And you know where to look for things that are modified And of course there's the Drupal 7 feature to separate the private files from the public files So that you can keep your public files in the document route and keep your private files outside the document route if you want to and There's not going to be accessible from from the web server Even if your server is not reading your hdxs file that is there. So there is a lot of considerations around that I Would say it's ongoing to secure that and we probably kind of improve on on that in Drupal 8 I've seen the issue that separating the user modifiable and the core distribution parts of Drupal to different directories It's set to be going to be committed somewhere later this year But it's breaking so many patches because it moves around everything that it's delayed for the fix ups in Drupal 7 To get in and then we can like make even more bigger changes in Drupal 8 Any other questions? No, then thank you. Thanks for being here