 Thank you so much for coming. Does anyone know this one? This satellite? This was a project from NASA in 1999 and it was destroyed halfway because the satellite used a satellite and the engineers used inches. This is literally rocket science and people blew these up. And this is Samsung Galaxy S10, the phone came this year and it has fingerprint sensor that you can put your finger on in the display and it's supposed to unlock the phone. This is also failure because they forgot that people actually use screen directors on the phones and it didn't work. This is HardBlake, the icon. This is 2014. There's a library called OpenSSL and this was here 250 but 90% of all the servers in the planet, they were vulnerable. This we probably know, 2014. We have a name but I don't want to tell the name. This is line, just one line and pretty much every group of scientists are vulnerable and eight hours, pretty much every scientist started to get attacked. We repeat the same thing. It's not the same vulnerability but 2018. And this is from JavaScript because PHP and JavaScript we both make mistakes. So the author of this plugin, they give the plugin to someone else to maintain and this new owner, they put JavaScript that tried to steal bitcoins. So you can see it patterned here. These are people. These are some of the most modest people and one of them there, it has literally rocket science and people, we always make mistakes. I have made so many mistakes when I was coding and I'm going to beat all my euros that you have made mistakes as well. So there we go. We all make mistakes. And speaking of security, this OpenSSL vulnerability was a big one because this vulnerability, people started to create new libraries and Drupal, we had two vulnerabilities but here we are a room full of Drupal people because just because there was one mistake, that doesn't mean that's the end of the project. And sure we make mistakes but we can also learn from them. I like to highlight the fact that we just make mistakes and we are here to learn and we don't blame anyone. We don't tell anything bad about them. We just learn from the mistakes and we try to improve them. This talk is the last top 10. We talked about the top 10 security vulnerabilities we had in the past few years and we tried to learn from them. My name, wow, this photo is super big. My name is Ayush Kauran and since the last time I was in Drupal, Drupal Europe, I'm now a full-time traveler meaning I travel all the time. You can find me on social media and I was born in Sri Lanka. I'm a Github, Drupal here as well. So if you have questions you can find me on all the social media. So we talked about Kavasp. It's time for OpenLib application security project. It's an online community and it's free as in beer and free as in free speech. It's a community but they also have resources about online how you can fix security vulnerabilities, how you can try to improve these things. So here I'm today to talk about the top 10 vulnerabilities and about Drupal as well. Before I started to talk about security, now we have a room full of security people because we like security that's why I'm here. Security is a big field. We have so many abbreviations and there's no way we know all of them, right? But we have to focus on the basic idea why we have this and why this happens. So this field is massive. All these abbreviations, security people like to use abbreviations for some reason. But here we are today to talk about the top 10 ways to be messing up. The first thing I like to talk about is unexpected surprises because most of the security issues we have is because we assume that things will happen this way but it doesn't happen that way. We have some expectations. I'm a coder. I write code and sometimes we have front-end design. Sometimes we have project managers, all these people. We have some expectations but security is about breaking these expectations. We get surprises and they tend to be bad. Imagine you have a simple search form and people can type anything. For example, they try to find the bare foals. This is the form which try to show the search results here and you can say this is pretty simple stuff from PHP. This works and you can change this to meatballs. Still works. Does anyone see something wrong about this? Something that could go? Yes. If you have HTML that works because this is not bad. This is just beautiful. But if you start to put a script, this will pop up because here we have a JavaScript and for HTML it doesn't know the difference because we just show, print this HTML on the browser and the browser does it. This is not bad. This is bad. So the way it works is we have the image tank and if there's an error, we ask the browser to submit all the cookies to this third party website. This is pretty simple attack but this can be devastating. You can share this URL right here to 50 people or 100 people in this room and as long as the first time they give this page, the browser will submit all these cookies to this third party website. This URL, that's it. If this looks scary enough, you can just show this URL and send this one. This one is friendly enough, right? But go to this URL and this browser will send all these cookies to this evil website. Another use case, SQL. So we basically have this query, select all the posts from where the title is, the search query. Sounds good, works good enough. But if you put SQL in here, for the SQL server, that's it. We are just asking the server to pick a post that has the title by Strip Ruffles and they drop the same table. That's it. That's the end of the story. That's even the comment that I had to put this comment everywhere again, probably the same place. So the school, there's a kid with the name Robert Drayville students and in the school they don't have any protection for the database, the same thing we had before and database is gone. Another situation, because we are talking about surprises, this is XML. Did anyone know that in XML you can load files? Right. So XML, that's a feature that you can load a third-party file from the server. This sounds interesting, right? So of course, if you want to hack a website, then if you can upload XML, you can actually use this form to ask the XML parser, hey, can you go and take the data from this file and the parser will do it. Another situation, this is a pretty simple PHP class. So when the class is being distracted, we ask PHP to put all the contents of this file, all these contents, this file and PHP will do it. We also have a function called serialize, but PHP will convert any PHP object to a string, so you can share them, email them, treat them, or still do the database. But if you get them from the user and if there is a sign something like this and when you un-serivize them or as in you take the object back from the string, this will be executed. And although we have good intentions, this object, when you un-serivize it, when you extract from this one, you will try to die to this index PHP, meaning the site is gone. So the common problem we have here is that we can never trust the user, right? Because everything comes from users and they can be good users, they can be bad users and we never know. This is the web application. It's not something we talk to people each other. I have a chart that when you should trust the user input there. This is also interesting because sometimes we think we should be careful when we take something from the user, but what do we take them? It's also important because we shouldn't trust phone inputs. This is kind of obvious, right? You saw some of the phones. Okay. Core is from the URL. Makes sense. You can change them easily. You have the parts. Again, the same thing. Database records. Database is not a trusted source because someone else can change something in the database. It can be an editor or someone who has access to the database. So database records, they are not something that you can trust. You also have user files, VHU files, executable files. This could also be untrusted user input. You also have emails. Sometimes you can send an email and serve your processed email, which could also go bad. Cookies. You send cookies to the browser and you expect to get them back. But that doesn't mean the user can't change cookies. There are some other interesting things that I want to show before. Sometimes websites send specific headers that can be harmful. DNS records. You can put harmful payloads to the database. From then, DNS records could happen. Who is it? I have some examples. An environment variable. Mostly in luck servers, we pass some configuration values from an environment variable, which can be trusted. There is a vulnerability called a 2TB proxy, which happened because environment variables were not trusted. And everything else that comes from users. Pretty much everything, if you don't know the cells. Even if you know the cells. And if there are more than one person that could provide this data, this is something that we should not trust. And we will talk how we can protect against them. Before I come here, I did some experiment. And in my website, I send this header, x.5.5.6. And this one says drop table. And the one that you can't see here is I send a script as well. So it's a header from the website. And we have seen some website that it just timed the URL and it will send you, show you the HTTP headers that the website had. There are many online tools. I Google them. From the first page, I could actually find one. Google this website, enter the URL and it will pop up the script. This is live even right now. Where is the website? Try it and it still works. I actually find two. Sorry. Oh, three, four, and five. I just gave up because I wanted to keep this session smaller. The same goes for DNS queries as well. You can see I tried to send some script here. Again, DNS queries, they still did pop up. So you can see how terrible things are, right? We can't trust form inputs. We can't trust pretty much anything. And there are so many sites that are still vulnerable. So how do we prevent them? Because we don't trust user input. We have to have a set of rules that this is some value that I accept. And this is some value that I do not accept. So we can validate things. We can also sanitize all the input. And there's another one called SK. When you start validation, it means we validate the user input when we take it. If you have a user registration form, and if you have an email field, you can validate the email field right here. Because if you take anything that's not an email address, that's not going to work. So that's validation. We have to know the exact format. Because if you take a URL, you can validate it for a URL. If you take an email, you can validate emails. So this is a valid entry. This is not. Also sanitize them. Sanitizing means we accept the values, but we are going to remove the parts that are harmful. We can remove HTML tags or SQL characters that we use. And this is useful when you can't reject the user input. For example, if we get an email, we can't reject the email because we have already saved this email. So that's where sanitizing comes up. For example, if you get something like this, you can change this one and remove the script tags and keep the things in the middle. If you get a file name. So file names, you can't use a star character, but you can replace them with underscore. Drupal does this. If you try to upload a file to Drupal with the star name, Drupal will change the name to an underscore. Again, this is the same thing happens in Drupal as well. If you have a class name that cannot be a class name, Drupal will simply replace these characters with underscore and call it today. This is valid input. This is safe output. Escaping. This is also something we do quite often. The way we do this is we take the harmful effect from the input constraint and then we convert it to something that's not harmful. This also depends on where do you put the output. If you have an HTML form, if you have HTML display, you have to make sure that this output is not executed as HTML. But if you're trying to use this in SQL, you have to escape it from SQL because HTML characters are different from SQL. We have to depend on where do we use these strings. There's one framework that does this wrong. There's one framework. They run 30% of web. They convert values when they input. This is wrong. I will show you why. They're famous and does this wrong. Drupal is doing this really wrong. How do we do this? We replace HTML characters. If you have this one as user input, you can change them to a harmless output because in HTML, these things are called HTML entities. The browser will remember to match this one. So we get this one. This is not pretty, but we don't execute this JavaScript in the browser, so this is the same. This is the basic idea of sanitizing everything. If you have SQL, we escape them to be safe in SQL. If you have XML, we escape them to be safe in XML. HTML, same thing. MySQL, we can use prepared statements. We tell the browser to tell the SQL server, hey, this comes from the user. Don't integrate this as my own SQL. The browser will now see this one. So the SQL server will try to find posts with the title this, and it does not try to drop the table posts. So this is what you get. How do we do this? To validation, PHP has a function called filter bar. It has a whole bunch of parameters that you can ask them to validate against URLs, email addresses, all these things. WordPress also has one. So I did tell the word name WordPress in Drupal.com. Yeah. Drupal. We have a function called valid email address, and then you can, is it valid or is it not? You get a truth and false. Joomla also has one. So diversity. JavaScript as well. You can validate the email addresses. Here's some documentation for them. Why do I have at the end of the session sanitize them? PHP also has the filter bar, same function, but you can ask them to sanitize this email. So these invalid three characters, these phone strings, PHP will remove them, and then you can get the correct email address. WordPress also has it. Drupal don't have it because it doesn't make sense to sanitize emails. We can just say no. This is documentation, and we can also escape them. This is actually kind of important one. For HTML, there's function filter bar again, but we ask them to sanitize four HTML characters, which is for shortcut four is HTML special challenge function as well. Escape HTML from WordPress. Drupal has check playing from Drupal 7 by Drupal 8. So it has a similar function. Joomla. We also have from JS as well. Here's the documentation. So this URL, the filter bar function, it's a kind of new function, but it has validation features for pretty much everything, URLs. And this is, you don't depend on a regular expression or you don't depend on anything else. So I recommend that we start to use this function and not assume a special chance because what is a special chance we turn now. WordPress, all the documentation here for SQL, the way we can say to PHP that this is a valid, not valid, unsafe input from the user. We prepare a statement, and for this statement, we can execute it with the user provided value, and we can get the values back. WordPress also has one, Drupal. So it's similar to the same pattern here, and you can use as much as many as parameters you want, but we have a small limitation that if you use limit or order by, in the query, it has to be stripped out as in, it has to be an integer. Again, documentation. So do you remember the first example that they executed JavaScript? I told you this is not harmful, but it can be made harmful. If you put anything in a script that can steal cookies or do anything bad, that's what we call cross-site scripting. And do you remember the example that they somewhat could try to execute SQL? What we call the injection. And the one that we had XML, and you could include files from this XML, we call them XML external entities. And this one that someone could try to change these values and delete the file, we call them insecure serialization. So the topic is about top ten, and we have it here at four. So most of the talk is about these four, because I work as a security researcher, and you have probably seen my name in some of the emails that you get on every Wednesday. These four accounts to pretty much every security issue they have. We just forget to sanitize some form fields or templates. We sometimes forget that, hey, this is user input. We just forget these things. And these things are bugs. It's not a mistake that we should be ashamed of, we just forgot to do it. So talking about injection, never trust your input, remember the chat about it. Use parameters like from the example before, and don't try to scamp your own SQL. Because most of the databases, they provide a way to pass parameters. For example, MySQL has, for like queries MySQL has a percentage sign, but not every database has it. So try to use the database driver tools. And the other thing, HTML and email headers are vulnerable, too. Because this is also user input, and I have seen so many examples and so many projects that they just forget that this is user input. Sometimes we want to, I have never seen people do this, but I can see in some other projects that this is. Sometimes you can ask users, can you provide a SQL query and they're now running for you? Never do it. Because there's a project called symphony expression language. They do this really nice. So the way it works is that if you want to have a query, and if you want to ask the user what kind of projects you want, and the user can type I need pause with the name is this one, or a pause with this amount of comments. Don't let them type SQL, use expression languages, or even rules maybe. You can also use low proof database users. This means when you connect to the database, you can use a user account that cannot access other databases, not the root. Definitely not the root. Cross-site scripting. Again, they have a transitive input. I have typed this, I come here to this site many times. Escape values right before you are outputting them. Again WordPress, this is the other way. When you put something on HTML templates, right before you print this, it can be a quick file. It can be template files, or tbl.phd files on 7777. Send them right before you output them. Because the value could be used in something else. And when we print them from the last step, we know that this is going to be used in HTML. Cookies. There's one example that someone tried to steal a cookie. And this wouldn't happen. When you send a cookie, if you mark this cookie as HTTP only, that means no one can steal this cookie. There's also a security header called content security policy. I have done a talk just on this HTTP security headers. I have a link at the end of the presentation. So from this security header, you can tell the browser to never load scripts from any other domains than the one you have mentioned before. Images. You can pretty much contain, if someone manages to access your site, you can use this header to pretty much contain the damage that they can do. Mod down. Because we can't trust sometimes we have, in Drupal a feature called full HTML. Which is actually full HTML. So sometimes when we work on projects, it's probably better to use mod down or similar mod languages. BB code or something. If you can use them, for security reasons, because when you use BB code or mod down, you know that you can't put a script in it. PSG also has a job function that it does strip tracks, but it doesn't strip the attributes we have, which can be used to execute any job strip. If you see this function there's a very good chance that there's a security vulnerability there. So just drip for it and then try to find these places. Proper HTML sanitization because strip tracks doesn't work. They have to use a strip purifier or different projects to actually process HTML and remove all the bad attributes and all the bad tags. The other one is insecure in unsealization. PHP has these two functions serialize and serialize. They can execute any PHP they want. We saw some example before. And if this input comes from the user never unsealize it because we don't know what's coming up. Again, never transduce input and you can validate the data with HMAC. I don't have examples for this one but the basic idea is that you get the hash value of the thing that you want to unsealize and if someone changes his value, his hash wouldn't be the same. So you can see if something has changed. You can sometimes see because sometimes we have old computers that use 32 bit registers but if you unsealize it to a 64 bit you can still get the value but if you do it the other way it means we get a popular integer workloads. You can read more about it but I try to keep this thing smaller. XML entities. So PHP has this function that you can just disable this and call it back. You are really safe. You can also enforce XML schema because XML schema is a way that you can enforce that this XML value should follow this one. It must follow this standard and you can if you use third party decoders for XML you have to configure them one by one to not fetch files or not do anything else. So that's about unpleasant surprises. If just when you look at the project check all the outputs and check everywhere that you accept a new input and see if there can be a surprise because I guarantee you because we forget most of the things we are just humans and I forget many things and we all forget many things there could be about two ways that someone can sneak in and if there's just one that means they can escalate themselves to be anyone inside. Pretty much every security issue I have found so far they belong to this one. Not something that we talk about decrypting something it's 55 computers or anything it's just simple mistakes that lead to bigger issues. The second chapter is unpleasant visitors. All these photos by the way they are from National Geographic one of the best photos from each year. So we have a site the URL and we show some information it doesn't have to be Drupal some website it's pretty simple right Drupal has the same pattern user slash and then this is actually my Drupal user ID. You can go to this page and it will show my information but if I change this ID to something else and if you don't have any protection to prevent someone from accessing this information that you are actually leaking information of all the other users. In Drupal.org you can go to someone else's page and this is allowed but sometimes you just forget to bring user profiles and that could lead to data exposure. Also we have this edit URL this by the way is any phone just pretend it's any phone. Change the user ID and if you don't have any proper authentication proper authorization to check if the current user can access this URL if I use a 7981 whatever that user ID I shouldn't be able to edit someone else's profile and sometimes this is super simple thing but we actually forget that we have to check the access for this one and we have a name for it this is Drupal Access Control because it sounds simple but we have to check every page or every action to make sure that the user that we have logged in or the user that they pretend to be they have access to it. We have seen this error as well we get the white screen and then we see this error message we have seen this multiple times before right but this is like information if you look at this one you can see just from the error message you can see that they are probably using MySQL and from this line you can actually see there's a file called inventory slash db.php and on line 8 we try to do something so this is some sort of information that we should not show to someone else attackers they could use this because now that we know this is using MySQL so we can focus our attack on MySQL and this is data exposure this is from xDbug if you have the xDbug extension it will screen all these error messages with the whole address whole abstract address so you can see all the class names the file names, the numbers there's so much information that you can find just from this one and these are error pages it's not something that you check every day and because this error message you won't need to be super helpful but it's also helpful for attackers as well so combine these error messages or stack traces or any error messages you show this is what we call sensitive data exposure because these data they are not meant to be for regular users this is sensitive data and then we show them to anyone who manages to access this page and the other one we have a login page and imagine this is login form we have seen all these choices, right the password must be less than 8 characters we try to sham all the banks with 8 character passwords or sometimes we have things like this passwords should not contain these characters or something like this like ridiculous ones passwords must be uppercase and you can't classify passwords so all these password advisors all these login forms and all these information all these restrictions they come from some kind of myth that you're trying to make this form secure but you're actually making them insecure because if my password is 30 characters long it doesn't matter if I'm using the special characters because my password is long enough to be secure enough and this is broken authentication we have some examples about this as well so back to top 10 we talk about 3 more 3 to go sensory read exposure sorry, sensory read exposure hide or error messages just we should not be showing technical error messages to users period error logs, you can log them to error log so you can see later and what went wrong but it's not useful to end users and it's actually super useful for attackers so keep them in the logs but not to show them exceptions and error handlers so a 08 and 08.9 all the way to 9 we try to use exceptions as much as possible and sometimes if you don't catch the exception this is a PHP way to say that if there's an error I want this error to be caught and if you don't catch it it means it becomes an error and this whole error message is going to be shown to end users so you can set exception handlers to make sure that all the exception handlers are going to log them but not to show to users you can this you have probably seen this one as well so when you visit the website it shows you are using PHP 7.2 or 5.2 it would help you if you do it all these versions you don't have to show them and sometimes this is pretty common in PHP Mailer the old Mailer client it shows which file the email was sent from the PHP version and PHP Mailer version we don't have to show these versions but the plugin does it so you have to hide all this information as much as possible user passwords when you store user passwords don't store the plaintext passwords WordPress does it so Drupal definitely does it always use a GPS this is kind of given right and also be defensive because we can never trust these users and if we try to be defensive if we don't show information to anyone that's our take that's the stand that we should take authentication always hash with passwords like the one we talked before so Drupal 7 they use a library called PHP and speaking from a security perspective it's not the most secure solution we have so I wrote the plugin to use PHP password hash plugins I wrote one for WordPress as well and you have probably heard about these hashing algorithms FD file and all these this is like 3 years old even the char hashing algorithms they're just hashing algorithms they're not good enough to store passwords so also always use this function password hash and password verify if you use Drupal you're good but if you write something at PHP you can use these functions there's also the rule about don't use these special characters so you must be using these characters you can see many of the projects nowadays they don't enforce this one so if you are a bank please don't do this and there's also advice about protecting passwords there used to be an advice that you have to change the password every 3 months so every 6 months there's tend to be a bad advice because we have password managers today and the password managers will create a secure password and then it will just store there and there's no reason for us to change the password every 3 months and if you're off the user to change the password they just put one at the end of the password anyway so don't there's no good reason to do it sometimes password must be 6 characters, 6 pages long and should not be longer there used to be some things restrictions like this so in the security camera we say at least 8 characters that's the minimum limit and then you can go to 72 this sounds like magic number but we Drupal and WordPress all these PHP frameworks we have today the 72 is the number that the underlying library called Bcrypt can handle so if you have a password 72 characters long and 72 that's actually the same password so 72 is actually pretty long enough at Drupal there was a security vulnerability a few years ago that you can send a massive packet to be encrypted and it can take down the site because the password hashing input is so long Drupal has to spend a few minutes to hash this password so it's good to have a maximum limit as well password reset forms I like to say password reset forms are backdoor because sometimes you can create the most secure looking form and the password reset form is terrible so there's no use for it trying to secure the password reset forms as much as possible as well in Drupal we are kind of golden because after 5 attempts Drupal will block the user saying hey you tried too much slow down if you tried to write something by yourself there are so many good advices that you can take from Drupal don't roll the own crypto this is kind of like a slug for cryptographic community don't try to invent your own password hashing algorithms because the one that we use on PHP called bcrypt and argon2 they tend to be researched really well they tend to be much better than the one that we write on hand because of something broken access control now the one thing that we should remember is that HTTP is a stateless protocol just because the fact that the user acts at this page it doesn't mean the user is allowed to that page so for every page or every request, every HTTP request we have to validate that the user has access to do this because HTTP is stateless you can even copy one request and then try to repeat the same request once again and do something bad check the access from the user as well as possible because you can say no if the user5 is trying to delete the form from user8 you can just say no and there's no reason for you to check it after so these all access checks they should be done from the beginning of the request if you have forms that change anything deleting something, updating something they should be forms of the time post and not get because HTTP standard says all the get forms should not change anything in the application use post forms for that there's another one called proceed request forgery this used to be one of the vulnerable areas from hospital 10 but not anymore Drupal does this really well if you have a form there's always a random looking form at the end of the form a field at the end of the form this is to make sure that no one can submit the form without actually seeing the form first Drupal actually does this really well so I have not put an example there but there are some projects that you can I have written one as well that you can generate CSR token you submit the token along the form so you can validate that this is actually a form that you send to the user first this is a new one when you send a cookie you can similar to the one that you send HTTP only there's another flag called same site so when the browser receives this it doesn't send the cookie to any other request that comes from different sites this kind of works as a way to prevent people from pretending to be someone else again, you send GPS everywhere and the last piece that we have is negligence this one is security misconfigurations higher messages, we talked about this before low gather messages but don't show them we have secure protocols code TLS and SSL SSL can't use them TLS 1.2 and 1.3 they are the current standard ones database snapshots and the files they have backup minded module if you leave all these files without proper protection someone can try to download the database and access folder information change default passwords this is kind of a joke from MongoDB because when you install MongoDB there is no password at all and if you don't change passwords anyone can access MongoDB database SSH access sometimes we use simple passwords for SSH but you can change them to use a private key to access your servers we also have firewalls to prevent any IP addresses from connecting to them just a specific set of IP addresses components security vulnerabilities meaning use the latest PHP versions latest Drupal versions update to modules as well compose update you can update Drupal modules as well semantic versioning this is a way to show that this update will not break anything inside this update will break minor things Drupal does not follow this but you can always check from the each update that if this is going to break something security announcements Drupal we send out emails on every Wednesday about any security issues to try to keep an eye about them you can subscribe to security updates because the Drupal get it was in just 8 hours so it's important to be in touch with these security issues CI systems this is a way that you can test everything in the site for every change that you make so if something goes bad you can know that this is actually going bad before someone else realizes this there are two projects this one is Drupal security advisories if you install this on Composer and if you try to install a plugin with a known vulnerability Composer will show no I can't do this because this is insecure same projects for PHP as well so try to use these two projects I use them pretty much every project I have and the last one is in submission logging we talked a lot about logging because it's actually quite important exception handlers PHP 7 you can catch error handlers errors and then load the error messages but not show the error messages to the users log them to a file also we have system logs to detect when someone tries to access your server on SSH and if this was failed this is going to be this is going to end up in the log as well keep starting the logs there's even a GDPR regulations that you have to keep the logs for one year and delete them if the user wants to delete them which I don't personally agree with but that's the log and use the logs in a way that no one can change them so I pay known logs at real time on train there's only tools that you can detect if there's a sudden trafficking there's a sudden traffic spike and that kind of means something's going bad so back to top 10 and we talked about top 10 this is from 2017 there's no last top 10 for 2018 or 2019 that's because nothing has actually changed quite much last project started in 2009 and all these years injection was number one cross-section was on the second the second one and I tried to spend more time on the first few because that's where most of the vulnerabilities will be and that's the easiest one to mistake so then we go to the top 10 the things that we learned today one, never trust your input because it can be harmful it can be anything so if you see a user input anywhere be defensive, don't trust them security vulnerabilities, they are bugs just because I have made so many security mistakes that I should be ashamed of myself but I don't know really I'm talking about security that's nothing to be embarrassed about build security into pipeline like the project that I showed before if you try to install a plugin with vulnerabilities you should have some system saying no this is bad don't do it see ICD solutions that test everything when you update a plugin, update a module so build them into pipelines and the most important thing is raising awareness because I talk about security quite a lot and I see a room full of people interested in security and I have so much respect for all of you for being interested in security because a few years ago we used PHP and then we never cared about security and here we have a room full of people actually caring about security so we are halfway there if you see any security issues try to report to people websites or anyone and raise awareness I have a bunch of further resources some of this is a talk that I gave a few years ago so it has more information about HTTP headers and there is also a URL that you can solve in a survey about Drupal code itself the first one is the last top 10 it's a wiki, you can edit them as well and there is plenty of information that you can just read and this filter function this is about the new function but it can do so many things as well last, any questions I'm going to repeat the question if you have any the question when it comes to the user ID with Drupal everything is like node slash node ID I've always wondered the security vulnerabilities with having it pretty predictable and if I wanted to go to a site that I figured out as Drupal I could just go in right through however and see what I can find but do you have any sort of insight into that so the question is about trying to guess the IDs and just iterate them from one to all the way and see what kind of information we have Drupal we have granted access so you can actually prevent people from accessing nodes that they should not access but I don't think we have any solution to prevent the node ID thing but you can change the router there are some pages called I think UUID that you can generate quite long strings that's quite difficult to guess that there are some things that you have to consider because I remember my Drupal ID but if it's like a super long string I probably wouldn't remember but for projects like this I think UUID module in similar projects they can actually change the way the nodes or use anything that access you can also use URL alias and if it's a use ID you can just say no you have to come from the user alias URL alias it's not the best solution but I think that's what we have okay we talk about HTTP headers which shouldn't be verbose which shouldn't describe the platform the software that you're using you have a solution how to cut this in Drupal Drupal actually sends a meta tag saying hey I'm using Drupal 8200 for Drupal 7 I think there's a plugin to just hide this it's a super simple plugin but you can hide it as well okay sorry so you can provide feedback and we can any questions I will be under the first please wait for the thank you slide I spent like half an hour to make it