 Welcome to securing your Drupal site hopefully that's what you're here for You're here for securing other stuff. Maybe this is relevant to you But if you're not here for security, then then we've got a bigger problem So my name is Greg can Addison and I'm a member of the Drupal security team and very interested in security Yeah, these slides are online by the way, and there's a link at the bottom there We'll also tweet about it after the presentation So I'm a Greggles on Twitter Greggles on triple or Greggles on IRC I've been working with Drupal for a little bit over eight years now or a while of eight years I've been working with secure with the Drupal security team for most of that time I wrote a book a couple of years ago called cracking Drupal Don't be surprised by or thrown off by the fact that it's mostly about Drupal 6 because it is still relevant to Drupal 7 and Drupal 8 amazingly enough We'll talk about the changes, but most of the things got easier and the principles still apply I work at card.com. We're a mobile alternative to a traditional branch bank and we are like so many people hiring but if anybody is interested I'd be I'd love to talk more about that And I'm Stefan Koskett. I'm score on Drupal.org I've been with Drupal for eight years. I'm a member of the Drupal security team I'm into the RDF modern core and I also work in the Semenewebin Contrib I wrote a couple of chapters for the definitive guide to Drupal 7 and I work for Acquia and we're also hiring So we have lots of things to cover today, although we will only touch lightly on most of them This is just an hour session. So we'll talk about server environment server config personal best practices Drupal configuration a bit of code and Yeah, that's pretty much it. So we start with some general tips Whenever you use any kind of protocol You should you should try to use the secure version of the protocol. So not HTTP, but HTTPS SSH instead of ternet and SFTP instead of instead of FTP You should enforce if you care about your site and your Properties you should enforce a strong password privacy So that your passwords are not easily Gassable Make sure you also your servers your lamp stack is secure on your production and any kind of stage environments and If you maintain if you manage your own hosting There's a trick you can require SSH keys and not let users connect to your servers using a password. So This is all configurable on your servers Another best practice is to take and especially verify that that your backups are actually working And there's also a link in there to show you how to sanitize your backups if you want to share them With your developers and you have data that is private more tips Keep an eye out for your roles and permissions on your sites Make sure you don't grant two higher permissions to to untrusted users and Other tips to keep your sites your site sitting secure So look at permissions Yeah, the text formats can also be made insecure. They they are by default secure out of the box in core, but if you go and change the settings, which oftentimes you have to Be careful not to not to open security holes in your Text formats and we'll talk a bit about that there If you're using triple seven Guess nobody's using triple eight yet Make sure you don't have the PHP module enabled it's not a best practice really but Some people still use that and If you if your site if yours if your site get hacked and some of the access to the admin account they can then Penetrate your site by running PHP and There's also there are some modules contribute that also execute PHP using the adult function So that's that's not good keeping an eye out for that for those. I think it's like some editors to that so So here is a list of modules With links so again, you can go and check out the slide here all the links are Live so you can read more about each of those modules but secure login Enforces HTTPS on your user login form Primalia is to Threaten your site settings and it makes sure for example that people cannot turn on the PHP module Another thing that some people do is they remove the PHP module from core and charity on their on the code code base Security review Greg will do a demo of that later permissions lock it's a way to Make sure nobody even if you know not even the site admin can change the permissions on the production site yet You have you're maintaining those permissions via code. It's a bit like CMI interpolate or or features so That's also in a good a good module if you want to you're worried about security TFA or two-factor authentication that's Module more and more popular now It's what same same as what Google offers of github You basically have to provide two two kinds of authentication before you can get access to your site So oftentimes like I have a nap on my phone that that When I log into my site, it's gonna ask me for a token even from my phone. So Hacked is a module that will scan your all of your country modules and make sure none of them were hacked And it does that by just comparing the code from your code base with the code from contribute on triple the log and password policy I mentioned mentioned that earlier so You can enforce a specific password policy or certain level of password policy when your users Create a password on your site So these are all contrary modules. You can download it from free from triple the log so they are also All their other aspects when you're considering Making you know securing your site Think also about hosting so it's not only a matter of having a configuration a triple configuration bulletproof You can get hacked if you're underlying stack is not secure, but There are some hosting companies out there that can help you with that So plenty on is one example They provide an interface where you can Maintain your code these obviously they they have all the all the They keep they keep their servers up to date and they keep the stack up to date when it comes to Linux patches and stuff like that but they also have an interface to allow you to keep your Drupal core up to date whenever there's a new security release Which happens every few months, you know So they have a nice UI that makes it very easy to merge upstream changes and patches Acquia cloud is another product And insight is in particular is a tool that lets you kind of do an analysis of your State of security in your code base and in your configuration on your site So it will go into database and analyze all the settings that you that you have on your site And it will give you a score Whether or not you're very secure and it will also tell you how to fix things When you're when you have wrong settings or insecure settings And there are many other hosts entrepreneur dog. You can go and check them out So Like I said All of these hosts and most of them are tuned for performance, but also security when it comes to Drupal So all the file permission and all that that's taken care of for you You can also subscribe for services where The company will manage your security updates for you So that's one service that Acquia offers. It's called remote administration. And so you can you can subscribe for that So you don't have to worry about the updates yourself, so we wanted to throw in a few acronyms here So this just to remind you that depending on the kind of sites that you host and depending on the kind of content that you That you have on your site You might fall under certain regulations So if you have an e-commerce site most likely you have to comply with PCI So there's a there's a link in there for PCI compliance report That was written by someone from the community so I'll check check it out if you're if you run an e-commerce site and Do we have anyone in the room? dealing hosting and keep a keep an environment Dealing with so this is generally having to do with healthcare data Any kind of personal data? There's also Fed ramp fees my certification accreditation. That's for the government Again, some some hosting companies can provide this kind of regulations. They have those built-in. It's part of the contract Anyone knows What's got eyes or One person and using Drupal first get in a scat environment Okay. Yeah, it's not it's not so common then So It helps to think of security as a process as opposed to a feature So it's not something that you can think of Once and then forget about it It always have to be in your mind checks every now and then monitor So it's an ongoing maintenance It means that You also have to plan for it. So you need to have a budget for security when you plan for your project You need to plan hours for your developers and also resources for You know servers and all that like a proper hosting infrastructure and You know many chose thing can offer that if you can't you don't want to think about it And also when it comes to Drupal and and the code basis of all the contrips and core Drupal that all coffers are packaging infrastructure. So you should definitely take advantage of that. It's free and it can Let you know whenever one of your modules one of the modules that you're using is out of date and has a new security release. So That's part of core actually you just have to turn on the update module so So Drupal has its own security team. It's composed of volunteers and so Greg and I and Michael sitting here in the front a part of the team Oh So our role is to keep Drupal's code secure In core as well as in contribe So we work with the community and we try to Educate the community on the best practices when it comes to security and that includes developers obviously But also the site builders the site admins the users the decision-makers it concerns everyone so You keep everyone needs to be kept in the loop and that's why we have security advisories for every Security release every time a module gets a new update and your release because of a security bug We rather an advisory for it. So There's a new graphics here. I won't go into detail, but I invite you to check it out later there's a link at the bottom of the slide, but Essentially it illustrates the workflow of what's happening inside the security team. So at the top Basically the first step is we get reports from people who found Who think I've found a Renovated in the module in core or in contribe and They send us an email or the file of a ticket in our issue tracker So we'll take a look and if it's a valid report we'll contact the maintenance and We'll work with the maintenance to get them to fix their module Whether it's a pro site scripting or any kind of issue with security It's not a security issue then we'll invite the reporter to File a bug on triple the law and then once we've we've worked with the maintainer to come up with a good approach to for fixing the bug will Do us an advisory and we'll do a release and everyone is invited to Upgrade their modules. So So I wanted to you know, this this presentation is for site builders and we wanted to talk just a little bit about some code elements and And as we were looking at different vulnerabilities and which ones were would be worth talking about You know, there's the OWASP top 10 Which is what the open web and application security project feels are the top 10 most important issues that are facing the world and I think within a framework We have to take a slightly different perspective about what is the most important because the framework can provide some benefits and protections That make it different from just working on a web application in general. So this is looking at code vulnerabilities from all time and if you go by this list Cross-script scripting access bypass and CSRF are the most important issues I think it's it's also interesting to take a look at it in terms of Vulnerabilities as a percent of the total vulnerabilities over time So one vulnerability that we're not gonna talk about today is sequel injection Which is a super important issue because it can be really damaging to your site But what is really interesting to me about this graph is that sequel injection, which is in in green it goes from 50% in the first year that advisories went out from triple.org It's gone from 50% to basically zero percent. So I mean that's Let's see. That's up through October of last year. I think it is so that's in 2013. There were basically zero sequel injection vulnerabilities So we I think that basically what that really speaks to is the strength of Drupal's database API and Particularly the database API in Drupal 7 which has just made it so much harder to create a sequel injection vulnerability What we what we can also see is that you know cross-site scripting has been a problem and continues to be a problem Score we'll talk a little bit more about that later on and what we can potentially do with twig and Drupal 8 to try to address that We we can also see that cross-site request forgeries, which is you know, relatively new Or sort of newly described newly discovered issue It's been around for a long time, but people didn't really think about it until fairly recently So that's sort of like came on to our radar in 2007 And it became bigger and bigger and is sort of trailing off now because I think that the patterns for dealing with that are more Well-known and people sort of understand it a bit better in Drupal 8 There are some improvements that again you'll see more about that later and then access bypass is increasingly a huge problem for us So I think that that's something that we'll have to try to address in future revisions of Drupal core So the three that we're going to talk about three big ones cross-site scripting CSRF and access bypass So cross-site scripting is some sort of XSS is cross-site scripting It's some sort of code that is running in your browser people often talk about it in terms of being javascript But it's not necessarily just javascript It can be any other code that executes inside of your browser environment that has access to The DOM to your cookie to the URL to different bits of information like that It's able to make requests to either your site or to other sites on the internet and then potentially parse the responses and You know, this is like the sounds perhaps to a lot of folks like Ajax, right? That's exactly what Ajax does or exactly what flash-remoting is all about people to flash game on top of Drupal That's how your game is supposed to work So the idea is that you know sure you can use javascript to build rich interfaces or you can use it to attack a website Same tools with a different purpose So, you know if you're trying to test a site for cross-site scripting What I like to do is use, you know There's a couple of different ways that you can Demonstrate a cross-site scripting issue and if you try out, you know, both of these strings you will catch the majority of Issues there are sort of some less common ways of executing cross-site scripting But the idea is that you want to break out of Whatever the context is the HTML context and just have some sort of a new tag that's being displayed So variations on these will catch 90% of cross-site scripting examples according to my very scientific Throwing a finger up in the air and coming up with So how do we how do we fix cross-site scripting? A common reaction is to say well, you know We should validate inputs and make sure that the input doesn't contain javascript But you know if you look at Drupal.org for example, there's javascript everywhere That people have input because they're saying hey, how do I get this javascript to work? So you can't just remove javascript from the inputs because it might actually be the content of your site Instead the really the right way to deal with it is to filter the text on Output to the browser and you want to do that as late as possible But ideally before the theme layer is sort of the standard so that the protection is part of what the code That's always going to run That way if you switch the theme you're not going to create a vulnerability because the text has not been filtered yet And really you know again. I talked about the idea of the framework providing protections Drupal has a lot of protection for cross-site scripting built into it so the Set title function has changed from Drupal 6 and then in Drupal 7 now it automatically will filter text for you That's just one example But the tools for translation the t function that also has filtering built in to protect against cross-site scripting So here's a Here's an example if you have some text that you need to explicitly filter because you're not passing it through a function like T or or Drupal set title or whatever This is a way this is a flow chart for figuring out what you should be doing in order to properly filter that text And I think that this is is linked but the idea is you know you just start off and say okay Is this a URL if so I'm going to use check URL on it Is it plain text and it's important to think about plain text that you know if there's a Like a greater than sign inside of the plain text then check plane will turn that into the HTML entities so that it is Printed out as you know ampersand GT Semicolon is it rich text and rich text is sort of you know that that Has a special meaning within the Drupal world really that's any sort of text that has a format associated with it So a node body is an example of rich text in Drupal where there is a you know People choose a specific text format to use Associated with that piece of text and so check markup takes not just takes two arguments Not just the text itself, but also the appropriate format to use The next one is if you have you know some HTML So an example of this might be a label to display next to a field Then you could use filter XSS on that and then finally if it's truly quote-unquote trusted text Then you can just print it out directly And the idea there is that you root like you really really really have to trust that text So an example would be like if you're inputting JavaScript to be executed as part of the Google Analytics Scripts on a page. Okay. Well if you filter that for JavaScript then inputting the JavaScript isn't going to be very effective So the way to keep a site safe in that scenario is to just use a an elevated permission Associated with inputting text on to that form All right, so access bypass is second biggest and one of our fastest growing issues And this is really just people can either see something or do something on a site that their permissions Or that their access on the site should normally prevent And I think what makes this so tricky is that we enforce it in Drupal in just a ton of different places So you know starting at the very beginning of a request there's the access callback and access arguments associated with a menu item Then also sometimes sprinkled throughout various functions and you know the theme layer there might be a user access call We have the node access system that has to apply to any queries or just you know printing out a node that's been loaded There's the entity access system provided by primarily primarily by the entity API module individual field access You know if you have custom callbacks in other places, you know like you have a custom PHP function You might have to do your own checking of permissions and then again, like I said in the theme layer in templates so it's really just sort of all over the place and I don't know that there's a way to really consolidate this and make it You know harder to harder to screw up So I would say that the best solution here is really to just you know do a lot of testing whenever you modify stuff related to access and You know ideally have automated testing that will run those tests for you So when I'm looking for looking at a site and trying to identify situations for access bypass I usually do that just by sort of poking around on the site accessing URLs as an anonymous user or as a lower privileged user That I might want to try to access or that that might normally be accessed by an admin You can also look at the menu definitions inside of hook menu in a module file and Look for anything that uses for example percent node or percent user See if there's any sort of a variable that's getting loaded as part of that function and switch from you know node one to No, 20 and maybe you know if no 20 is one you shouldn't have access to either because it's unpublished or because of a node access module And just try that out and I really encourage people to use be hat Unfortunately if you're here that means that you're not seeing niches presentation on be hat But it'll be you know online later today or tomorrow and you can watch it then it's a great tool for testing stuff Like this in an automated fashion So how do we fix it? I sort of mentioned this in in how do we how do we? Or at what layer layers do we? Deal with the access system But there's you know as I said user access function for permissions node access for any sort of a content access module There's the entity access function If you're writing a query using Drupal's Drupal 7 database API Then you need to be sure to add the tag on select queries in particular And then in menu definitions make sure that the arguments that you have there are appropriate. I feel like a lot of times as developers People will just copy and paste it a menu definition And it's not quite working And so they set the access call back to true and then it starts working and you just walk away, and you're like great It works awesome But then that's going to mean that it's accessible to everyone All right, so the third kind of vulnerability that we're going to talk about today cross site request for trees this is a path that takes some sort of an action and It does not confirm the intent of the user And I feel like intent is sort of a tricky thing for a computer to figure out since that's like our emotions and you know I know that machine learning is pretty advanced, but I don't know if they can figure out people's emotions about their intent So the way that we figure out somebody's intent in a way that is reliable is using a nonce or a token that is generated That uses some information about the user some information about the site and some information about the action that's about to be performed and by combining those three things into a token and Associating that with the action as the action is requested. You can be certain that the user actually intended to do that So we'll have an example of this later on But you know, how do I how do I test for that or how do I look for that when I'm evaluating a site? One thing is looking for people who access to superglobal So dollar underscore get dollar underscore post if you see that in code It's worth inspecting a little bit further and it's possible that the person really knows what they're doing and they intended to do that But it's commonly the case that that's an indication of a mistake of a cross-site request for particularly if you're taking action After accessing those variables And then you know Drupal get token is the function that we use to protect against cross-site request for trees So if you see accessing those variables without, you know, confirming a token The other thing is looking for a verb menu So I'll look at a again the hook menu definition and see something like you know delete slash all content Right, and if you don't see a Drupal get token or associated with that then that's a concern So how do we fix it? So I mentioned the idea of a Drupal get token Drupal validate token or you can also use the form API So Drupal's form API since I think 2007 2008 has included this feature by default And so if you're building a form using the form API, then you're all set Or if you're building up your own custom callback, then you know you have to use those two functions without tokens There's some videos and more documentation on the Drupal Scout website as well So now I'm going to give some demos of cross-site scripting and access bypass Okay, so so I mentioned You know this is somebody who's logged in as an admin So they have actually the permission right to to do this kind of stuff, but all just look at that It's a score already has some JavaScript for me to just copy and paste here How's it is the font size okay, so made it back to the room. Yeah a little bit bigger. Okay So the idea is that you know if you have oh this yeah So yeah, if you know if you allow somebody to input full HTML into your site Then that means that they have the ability to input JavaScript into the site And so this is you know, this is the warning sign right and what you can see is that there's actually only one of those that Executed so I put JavaScript into two different places one of them, you know the title of the page Used the check plane function on it in order to before it output the text and therefore it's filtered And it's displaying that script as content rather than executing it as part of the HTML as part of the code So it's the second one inside of the body that That executed as JavaScript So, you know as an admin okay fine. That's fine that I can enter JavaScript It's actually maybe part of my job and part of what I need to do But if you're anonymous users or if you're untrusted users on your site can do that then that's what would be a problem So then there's another Wanted to show an access bypass scenario. There's a module called the invitations module. Does anybody use that? That's many people That's that probably makes sense because it was unsupported about three months ago for a security vulnerability in it In the oh invitations is the name of the module So what it did Is a lot, you know provided a way for you to invite people to your site and it generated a token that they could use in order to join the site but it defined a view to show that information and That view did not have any permissions associated with it So if you invited, you know hundreds of users to your site Then all of their email addresses and their special secret token were available to an anonymous user And they could just go to that URL if they could guess it and see that content So this is just like a checkbox inside of the view didn't get checked the view got exported into code And then now it's on you know people's sites So this is a very typical example of that access bypass. I feel like when we put that into an advisory I'm not so sure that it's clear to people what that means But you know exposing information that should be private inside of the site to anonymous or untrusted users Is an example of access bypass? So I'm gonna talk a bit about the improvements that we have in triple seven core so This is to remind people who are still wondering why they should upgrade their sites from to provide for six to seven that they should maybe consider doing it So Many many improvements came in with the release of triple seven. So we have a stronger password hashing and salting For all the user passwords. So if you get a database stump, you can't necessarily guess or reverse engineer the passwords which you could do in triple six There's a login flood control. So people cannot read force passwords on a given account There's a protect protected crown. So that's to avoid denial of service attacks up to triple six you could basically hammer the the crown URL and stress the servers and potentially bring your site down and We also have an update manager So it's a UI to help you keep track of your modules and find the ones that need enough to be updated that have a security release So this is how the UI looks like This in this example of use module has a security update required So it's go and upgrade from three seven to three eight There's also a nice feature that not many people know about you can get your site to email you when They are new security updates on your site. So That's all part of triple seven core update manager module Triple eight. So triple it also has new security improvements again So the major one that people are often excited about is twig. So to two advantages of twig It in theory it automatically sanitizes the strings on output. So Temers or even developers don't have to worry about it so You don't have to to worry about synthesizing your output and This is an example of code that you had to write when you were using when you're using triple seven So you did directly dealing with PHP at the template level So you could potentially forget to sanitize your strings. So here we have PHP variables PHP arrays directly coming in at a theme layer and If you're not careful, you might be outputting a raw string. That's not sanitized And that could lead to cross-site scripting in Triple eight with twig. We're not dealing with PHP anymore at the theme in the templates. We We're dealing with the twig language which first of all will only output Escaped strings and it's got it on its own Logic as well. So you still have if and else and loops and all that so Should be able to do pretty much everything you can do with PHP or at least all the things you need to do at a theme look at a theme level This is in theory. So there's an issue going on that See a tracks is working on that's what Dries Dries mentioned this morning in his keynote So it's a beta broker right now, but hopefully we'll have it in triple eight core with twig so The the other thing is You're no longer dealing with PHP in templates. So that means you can no longer have things like Escaped injections or or poorly write written PHP in your template so, you know Do advantages here in having twig so we also have a whizzy wig in core So that means what's good about this is that it streamlines the configuration So we have a mechanism that keeps in sync the whizzy wig settings and the text that are allowed in the whizzy We as well as the tags that are allowed server site In your in your filters, so we already had in triple seven the server site Restricted set of tags, but now we have we have the the whizzy wig configuration tool also keeping keeping those server-side and client-side tags in sync so the example with Triple seven or up to triple seven is Developers would often like struggle like me to set set up whizzy wig and they would end up Maybe turning on full html because that that works all the time and They would grant access to full html to potentially Authentic users or untrusted users or anonymous users and essentially give them access to to hack your site so There's also a neat little filter in triple eight that I don't think many people know about it's called restrict images to this site So it's a locate local image filter It restricts the images to The images you can include in your html can only be local images. So that means you cannot perform cross site Request for tree in on the on the other sites and I will demo this at the end if we have time and so to wrap up This session before we do questions and demos. I just wanted to mention Greg's book cracking triple There's a link in there you can just go and click on on the slides Chapter six of the definitive get a triple seven also has a chapter on security You can read about the security team and look at all triple scout is a list of articles focused on security Here is the URL to the security report and there's also a group on GDO for talking about security and So I just want to pitch in that we have Sprints on Friday. So if some of you are interested in contributing or learning About security and how to use the APIs that we have in Drupal and essentially we'll be focusing on Drupal 8 But it's it's a good way to learn what's coming up So you're welcome to join is the URL to to check it out all the details and Twitter So you can also come up to us and talk. I'll be mentoring on Friday. So I'll be helping anyone who needs help So local image look at image Okay, so I have I have set up a page here Which is which includes an image? right here and There's an image tag here with a link to a different site. So this is a D7 site And it links to the logout URL and this is actually the same sites here. So So if I go to this You're all this is the URL that I go to to when I want to log out of my site the thing is I'm working on my site right now and Just to make it here red So I'm working on my site. I'm logged in just about to new to add a new node and Someone else Has set Has set a link to this user logout URL. Yeah an image. So this is this is clearly a malicious user and I'm going to save that So now when I go and visit this node on my on my other brother brother I'm essentially going to be logged out from that site Sorry All right, so I got I got logged out of my site where I was editing content simply because Someone tricked me into visiting this page that has an image and a Sierra hidden CSRF in that image so what triple eight offers is This new setting Which is enabled by default by the way It's called Restrict images to this site So I'm gonna turn that on I'm gonna lock back in here. I'm like I'm just editing my content And now if I go here This time I have a Red image. This is basically a blocked image because this this image was not Belonging to this site and Essentially, it's protecting from CSRF now And so if I go back here, I'm still logged into the initial Initial site where I was editing my content So that's the one CSRF protection Offered with your blade was doing So we have So we have potentially some more things that we could demo But we'd also be happy to take some questions if you do have a question There's a microphone in the middle of the room which will help it to get on to the recording And we also want actually what we get people to ask questions. I forgot to mention Two things in triple eight We we have the PHP model in Drupal 7 and it's been removed removed from Drupal 8 again to make it more secure and I also want to point out the built-in CSRF tokens that we have now in The Drupal 8 routing system So if you have a route and you want to make it protected so the typical example is inhibiting a view Yes, some link We had views had several Secure advisories, you know in Drupal 7 because of that But now all you have to do is Add this option in your in your YAML file when you define your routes in Drupal 8 So this will add a token to every URL that gets generated And when you try to access this route, it will check that you have the right token at the end So this is neat and if you want to evaluate the session I know that the organizers are looking for feedback So you can go to this to the session URL and Give you feedback So now we're ready for questions Hi, thank you very much So you talked about sanitizing backups So if I if I'm making backups of my site What are some processes that I can do to make sure that I'm sanitizing those backups if I'm giving those out to developers? And maybe also if if I just want to have some backups for you know, if I need to restore from my site, thank you sure So the the idea here is that you should basically have You know a set of backups of your site that are perfect right that are exactly right and you verify that you can restore from those Very easily, but then you know like I think most people Work on their site actually on or in an ideal world, right? We work on our site in a non-production environment And so whether that's your local laptop or it's a different Different environment like you know some hosting providers provide non-production environments You don't want to be working with your live data in those non-production environments such as a laptop because you know Hey, we're all going through security at the airport and we leave our laptop in the bin and now You know you have to send a letter to the 50,000 customers of your website and be really embarrassed and You know that those are the sorts of things that are just a horrible experience to have happened, right? so There are ways to different script examples that people have created for Sanitizing your backups and this this links to an article in the aquea knowledge base about how to do that one of the techniques that I think is really great is a tool called Drush SQL Sanitize and so that is a It's an extensible system for sanitizing backups so you can write a Drush command that will sanitize information or it's just you know either deleting rows or changing data inside of rows Like changing an email to be user ID plus example calm right something like that and So by using Drush for it one of the benefits is that it can be part of the contributed module on Drupal dot org and then when somebody downloads that module they can get the benefit of that improvement so For example, there's the Facebook module FB dot module has a Drush Has a Drush component that will delete your Facebook secret token for your app because if somebody got access to that They could you know potentially modify your Facebook app and log into Facebook as stuff like that So that's one example of a contributed module that takes care of it for you But it's very important that you know You're doing that only on developer copies not on the copy that you could potentially be using for restoring the set. Oh, yes With the with Drupal Drupal 8 in the CFRF and the images not coming from the same site How does that affect use of a CDN? So that the the filter in Drupal 8 and there's actually a Drupal 7 port of it as well So the goal that it's it's Just sort of a useful tool for making sure that images come from a trusted source Basically so that people can't post images that are hosted elsewhere It has a side effect. You know CS are pretty images image tags are one way to To exploit a CSRF vulnerability, but there's many other ways to do it What really all you need to do is trick somebody into visiting that URL And so you can trick somebody into doing that by sending them a tweet with a shortened URL that ends up at that destination, right? Or send them a you know link in a variety of different ways that makes them end up on that page Use an iframe rather than an image tag So CSRF it's not an effective protection against CSRF Particularly, but it is a good tool for making sure that images come from trusted sources So specifically your question about using a CDN with that I believe that there's a patch to allow white listing additional domains so that you could have your site and potentially others But that patch has not made it in yet, and I'm not sure if that will make it into Drupal 8 But it could potentially be in You know a contributed module I didn't catch that you said the slides would be available. Where are they gonna be available? Yep, I just posted a link to them as a comment on the on the bottom of the session page So I encourage you to go to the session page and scroll down and fill in the survey and then you've got the link to the Hi, yes, so from a lot of questions, sir. Yes From your slides cross-site scripting looks like it was really popular in Drupal I was wondering you know you showed an example of an alert box But that was a very scary is what are some of the things that maybe we should be worried about with cross-site scripting? That could happen on our sites. Sure So cross-site scripting, you know the alert box is great because it makes it hard to ignore what's going on Usually when there's a cross-site scripting attack You won't know that anything has actually happened because the JavaScript just runs and it takes actions on your site But if anybody is a fan of musicals what I like about cross-site scripting is that anything you can do cross-site scripting can do better It it can make requests to your site change settings change the password Well depending upon which version change the password for another user on your site Yes, do steal your cookies and send your session cookie to another site and an attacker can use that to log in as you so Really anything that anything that you can do as an admin on the site cross-site scripting can do That's one of the reasons I really like the paranoia module because it prevents execution of PHP So that way if somebody has the ability to execute cross-site scripting the worst that they can do is whatever they can do within the interface They can't use your site as a pivot point to do further PHP attacks Yes Hey, thanks a lot guys. You mentioned using B. Hat Yeah, could you elaborate on that and give some maybe give some examples? Sure. Sure So just a you know super simple example If you have a site where people should not be allowed to see where anonymous users should not be allowed to see user profiles It would be like, you know two-line B. Hat test to say given I go to You know slash user slash one then I should not see You know some HTML that would show up on a page showing a user profile And and or you know given I'm an anonymous user when I you know go to user one whenever it is so that that's a Just one very simple example, but there's the Drupal extension for B. Hat It's a Drupal dot org slash project slash Drupal extension has some different tools that you can say given I'm logged in as a user with this role And and then you can list off a bunch of things that that person either should or should not be able to do And just confirm that they're getting you know an access denied page or a login page Or access denied page or they're getting the actual page And what I you know what I think is nice about that is that it's very easy to make mistakes with access bypass and It'll affect some totally different part of the site, but you don't even think about And so if you're not using automated testing then you're not gonna Catch all of the different areas of your site. I Think this might be my last question um So you mentioned like some modules for doing analysis on your site is you you said that there's a security review that you might demo Could you demo that one? Yeah, thank you So so the security review module is it's really a module written by a smart guy Doesn't provide a link to the reports from modules So I it's already enabled on this site and it's inside of the reports area And and the when you first visit it it'll say, you know, hey you have to You have to you know be sure to configure your settings So security review module doesn't know who is trusted or not trusted on your site by default It assumes that the anonymous user is not trusted which makes sense and it's it will Set I think the authenticated user checkbox based on your registration settings on your site and administrator the core the Drupal 7 Administrator role is assumed to be trust or yes assumed to be trusted You can also say like oh these things. I don't care about or these things and and check them off as things that should be skipped So I'm just gonna accept the defaults and then go back to the run-in review It uses the batch API because some of the things that it checks can be slow On certain environments or depending upon the size of your code base So there's a lot of weaknesses in this site Yeah on the locals at local host So this is pretty common right for a local host environment that to have a lot of issues And some of these things, you know, it's not like the end of the world a lot of them are Defense in depth issues so on their own they don't present a risk necessarily But they they may present a risk depending upon other configurations or weaknesses inside your site There are handy-dandy details about each of the issues so you can read through Understanding understand what the threat is or what the risk exposure is and then it also gives instructions for how to fix the issue Hey, um, thank you on the Restricting images to your current site. Is that a per image setting thing or is that global over the whole site? It's a peer text format setting so typically On your site, you only have a handful of them text format So typically you have like few or four maybe more, but it's you can go to configure your text format and it's It's right here in the enable features. So it's just a on and off setting where there's no other setting for it And yeah, so it's it comes by default enabled on the basic On the basic XML because this is a granted access to authenticated users And I know this users also don't have cannot post images. So by default again by default everything is secure Matter of you know keeping those settings secure and tight Changes for your config We're we're just about the end of our times So thanks very much for joining us today if you have any feedback you can leave it online or just deliver directly to us We'll be here chatting for a bit longer. Thanks very much everybody