 Can everybody? Can you hear me? OK. So hello. How are you guys enjoying the event so far? Is everything OK? OK. Well, I hope you're ready and set to go for the next 20 minutes-ish. If at any point you lose track of what I'm saying, do not worry. It is not you. It's me. Today, I'll be introducing you to front-end security. And I hope not everyone is a master in this, as I would really love for you all to leave here with a bit more information than what you came in with. For those of you who saw this presentation in Bucharest and or Cluj, this will not be the same. I changed a few bits and bobs. So although Cluj might have felt like a rerun for Bucharest, this will be a bit different. That's me for those in the back. I'm Maddalena, Maddie for short. I'm a senior front-end developer. And I've been working at Softesco for the past five years. This is my first time speaking at a con, third time speaking in general. They say third time is a charm, so we'll see how this goes. Now that we got acquainted a little bit, we can get down to business. What do you guys hear when you think of security and web development? Would anyone want to have a go at it and shout something I won't hear? OK, I'll tell you what I used to think. In the past, I would have been tempted to pin the security issues on the back-end developers or on the DevOps. From a front-end developer's point of view, I might have even pinned that on the QA department. Teach them to say not according to the design to me. We don't do security. We're mythical creatures. We take the designer's vision and the back-end there's implementation. And we make all of that look pretty for the final user. We make everything look flashy. Well, yes and no. I mean, we are indeed mythical creatures. There's no doubt there. But we also have the same level of responsibility when it comes to securing our web pages, just like everybody else does. The number of websites have, attack on websites, have increased over the years. And the internet has become somewhat of a dangerous place. We all heard of at least one case where millions of personal information have been leaked to the public. Users entrust us with sensitive information, like email addresses, social security numbers, credit card details, and such. And we're responsible for securing it as much as possible. Securing our websites requires a combined effort across the whole website. While it's true that the user data is stored on the server and accessed through the back-end, the same data is ultimately retrieved and displayed in the front-end application, creating an excellent opportunity to steal it. A front-end vulnerability happens when someone is able to harm your website application or users without ever having to gain access to a server to a database or hosting provider. Today, we will brush off the surface of this topic. We will look at threats and where they come from and what we can do to increase our protection for our web applications against the most common attacks, like SQL injection, cross-site scripting, cross-site request forgery, and then we'll look at some other threats. This QLI attack happens when an attacker is able to execute arbitrary SQL statements on a database through a web form field or URL parameter, making it possible for them to gain access and manipulate said database. They can access data on the server, create new identities with administrator rights, and just destroy or modify the data without ever taking into account the user's permission. The open web application security project rated the number one attack on the OWASP top 10 as being the SQLI in both 2013 and 2017. Hacksplaining said that if you only have time to protect yourself against one vulnerability, you should be checking for SQL injection vulnerabilities in your code base. There are four forms of SQLI, and we are going to look at them in a bit more detail. Incorrectly filtered escape characters. This happens when a user's input was not filtered for escape characters, letting it pass an SQL statement, making it possible to manipulate the statement performed on the database by the end user of the application. Let's consider the following query where we have a list of users with a particular name, and that name has been supplied from an HTML form. While entering a real name here will have no side effects. An attacker could change the behavior of the statement to something like the following. We see here that the text after the first SQL sign above was used as the username. The statement deletes the user table and selects all data from the user table, thus showing all the user information. This sort of attack happens because we did not make sure that the data that was supposed to be passed to the SQL query will not change the nature of it. A solution is to escape all characters in the user input that means something to SQL. If in our example, we would have escaped the single quote character, then we would have treated the name as part of a string. Now we have a very weird name as the whole string, but the string nonetheless. Web frameworks will often take care of this escaping for you. Incorrect type handling occurs when a user input field is not strongly typed or it is not checked for type constraints. If we will have a statement that uses a numeric field, but we won't make checks to see if the user did input a numeric value, we will just enable an attacker to add the string. So because the programmer meant a variable to be a number, but didn't check for it, an attacker could just add the following input, dropping all the users from the table. Blind SQL is used when a web application is vulnerable to an SQL injection, but the results is not visible to the attacker. The page with the vulnerability may not be the one that displays data, but will display differently, depending on the results of a logical statement injected in the legitimate SQL statement called for that page. This has been considered time invasive because a new statement needed to be crafted for each piece recovered, and the attack may consist of many unsuccessful requests. Recent advancements have all allowed each request to recover multiple bits, allowing for more consistent and efficient extraction. Second order SQLI occurs when submitted values contain malicious commands that are stored rather than executed immediately. In some cases, the applications may correctly encode an SQL statement and store it as a valid SQL. Then another part of the application without control to protect against SQLI might execute that stored statement. This attack requires more knowledge of how submitted values are later used. Automated web application security scanners would not easily detect this type of SQLI, and many need to be manually instructed where to check for evidence that this is being attempted. Before we go to our next thread, cross-site scripting, let's take a look at the basic concept of same origin policy. Soap means that websites are not allowed to retrieve content from pages that are not within the same origin. This will prevent random sites from, sites to read or modify data from a Facebook page, for example, while logged into them. This is what an origin is made of, a scheme, a host name, a port. If any of these is different, then we're talking about a different origin. Cross-site scripting is a way of bypassing this concept. It is basically an attack that allows malicious users to inject client-side scripting through the website into the browser. If an attacker will gain access to the cookies, like the user site authorization cookies, they will be able to log into the site impersonating that user and do anything the user has permission to. The main issue with this is that an attacker might be able to access credit card information, contact details, or they might be able to change your password. If they don't get to log in as the user, they might still read private details and make requests on behalf of the user. An example could be, we have a website where we enabled the comments without the proper validation. An attacker could submit comments which contain JavaScript that could run in the user's browser and steal the login cookie, making it possible to take control of the accounts of the user that viewed the comment. There are two main types of cross-site scripting, vulnerability, reflected, and persistence. So we're gonna take a look at those. Reflected occurs when the user content that was passed to the server was returned on the page without being stored. The script will be run when the new page is loaded so when the user clicks on the link. Let's take the confused deputy problem. A program which is tricked into misusing its authority is a confused deputy. Basically, you're tricking something into doing something that they're allowed to, but you aren't. Let's say George is passionate about adopting cats. One day, while looking at a shelter site, he sees an ad for the perfect cat. He sees that the ad comes from a well-known adoption service website, so he decides to follow it. The link looks something like that. I'm guessing that might not make much sense, but let's look at the decoded URL. We now see that the search parameter has an HTML scripts tag that might be trying to steal something. The attackers profit from this permission and use it to their advantage. Persistent vulnerability happens when the malicious script is saved in a database, for example, and later is executed for other users when they open a page. This is dangerous because the script is not visible for the browser's XSS filters and users might not only trigger the script when they visit the affected page. For example, this can happen if the username of a user that posts a comment isn't sanitized when it is printed, allowing an attacker to insert scripted code when creating an account. Their username could look something like this. The code is triggered whenever a user visits the page with comments from this user and gets the cookies of those users for the attacker. This kind of attack is very popular and powerful as the attacker is not required to have direct engagement with the users. We need to make sure that no one can inject JS content into our pages to prevent such attacks. We can't allow the user's generated content to be interpreted as something other than what we wanted. If in the above example we had sanitized our search parameter taken from the URL, we would have had something like this. We should only allow trusted origins required for the application to work and deny anything else. If we would have used content security to filter sources for scripts, the evil script wouldn't have been downloaded. Another good practice is to avoid loading scripts, images, styles, and other assets from any origin except the server. The best defense against XSS vulnerability is to remove or disable any markup that can potentially contain instructions to run code. The process of modifying user data so that it can't be used to run scripts or otherwise affect the execution of server code is known as input sanitization. Many web frameworks automatically sanitize user input from HTML forms by default. Even though most modern browsers have an inbuilt XSS filter, they should not be seen as an alternative to sanitization. Web browsers XSS filters should only be a second line of defense and the idea is to minimize the impact of existing vulnerabilities. Cross-site request forgery. This attack allows an attacker to execute actions using credentials of another user without the consent or knowledge of set user. This can cause serious damage to a person's bank account, for example. A third-party site can issue requests to your bank account using your browser with your cookies. So if someone was logged in their bank account in one tab, then another one could make the browser misuse the credential on the attacker's behalf. The trick here would be that the attacker doesn't need to have access to the user's cookies. The browser stores the information and includes it in all requests to the associated server. Other threats include click-jacking. In this attack, a malicious user, hijacks clicks meant for a visible top-level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but captured the login credentials into an invisible iframe controlled by the attacker. Directory traversal file and disclosure. In this type of attack, a malicious user attempts to access parts of the web server file system that they should not be able to access. This vulnerability occurs when the user is able to pass file names that include file system navigation characters. File inclusion. A user is able to specify an unintended file for display or execution index to pass to the server. Once loaded, this file might execute on the web server or in the client side. And command injection attacks that allow a malicious user to execute arbitrary system commands on the host operating system. But Drupal is secure, I hear you say. You go on and tell me. The use of Twig forces a harder separation between logic and presentation so that an inexperienced developer cannot put a lot of PHP in the theme, which can introduce security problems down the line. The adoption of CKE Editor in Core comes with an improvement in that core text filtering supports limiting the use of images local to the site, helping prevent cross-site request forgery. Clickjacking protection is enabled by default core JavaScript API compatible with content security policy W3C standard. Well, although Drupal websites are meant to be secure by default, we cannot rely on that. A beginner developer or a tight deadline can actually lead to making your Drupal site vulnerable. Security is an ongoing process. You need to follow closely, and it can help to have a little checklist. Let's take a look at some prevention tips with Drupal. Review content types to ensure that all sensitive information, such as user photos and other sensitive files, are uploaded as private files. Implement one or more of the Drupal modules for password management, encouraging strong passwords that are changed regularly and considering two-factor authentication. Filter anything that your application receives from untrusted sources. Filter inputs properly and think about whether an input can be trusted, which it shouldn't. Sanitize all request parameters and inputs. This is done by escaping all characters that kept being part of the code. Builds forms using Drupal's Form API to help protect against cross-site request forgeries. Keep everything up to date, modules, Drupal core, libraries, everything. This will help you take full advantage of the security fixes implemented by other developers. Integrity check. Your developers might modify core or contributed code. This can lead to complicated code maintenance and updates. Often, the vulnerabilities will come from bad configurations. Configure your web server to use HTTPS and HTTP strict transport security. Review roles. Block cross-site function. Drupal offers at least eight APIs to filter out and prevent cross-site scripting and block most of the script injection attempts. In parallel, Drupal deploys functionalities like HTTP posts to validate user intention and counter cross-site request forgery that can delete database objects. Anti-spam measures. Hackers and spammers have become smarter. Their attacks are not limited to the database table. They use bots to fill forms and submit comments on your site. Find out whether CAPTCHA or E-CAPTCHA are implemented in the forms. Avoid file uploads. If you do need them, some options are to rename the file on upload to ensure the correct file extension, or to change the file permission so it cannot be executed. Use vulnerability scanning tools to perform automated security testing on your site. Tools like Nikto, Sukuri, security headers, and so on. Some other tools you can consider. Security review, which offers a comprehensive report on areas that are prone to malicious attacks. Security kit, which prevents XSS and CSRF and clickjacking attacks. Hacked, which checks for modifications done to the core and contribute code. And coder, to check that the texts are sanitized. Fronted security flaws are mostly the result of tricking some components to misuse their authority. The techniques to do can be unexpectedly smart and hard to foresee, but some actions can be taken to limit the side effects. All sites have holes. What we can do is ask ourselves, when will they be exploited? How can this piece of code be tricked to misuse its authorization? The single most important lesson you can learn about website security is to never trust data from the browser. This includes get request data and URL parameters, post data, HTTP headers, and cookies. User uploaded files, and so on. Always check and sanitize all incoming data. Always, always assume the worst. These are some of the main places where I got my information from. I guess I have a couple of minutes for some questions. If anyone has any, please be kind. I cannot see if anyone has risen their hand, so I'm just going to say nobody has questions, and I can go home. Apparently, no. If you do have questions, I'm going to be outside there, and I promise I won't have so many nerves on one-to-one talks. So thank you all for your patience and presence. Hope you all have a nice day, and enjoy the rest of the event.