 Hi, everyone. Good afternoon. I'm Aadarsh. I'm a lead engineer at DGO. So myself, Thammi, I'm a back-end engineer at Strawberry, a USDA company. Today, we'll be talking about PyGOT, an initially vulnerable application returning Django to help us learn about web application security. So, coming to web application security, it consists of technologies or approaches aimed at safeguarding web servers, web applications or APIs against potential attacks from malicious actors. Now, talking of some statistics, based on an analysis on 14 million websites, we just found that an average website experience is 172 attacks per day. Also, over 60% of what traffic was observed to be malicious. Cyber attacks are costing SMPs an average of $25,000 per year. Also, these threats are increasing at an alarming rate year by year. Attacks include exposure of sensitive data, compromise of server systems, etc. So, we need to secure our web applications from these attacks. Now, let's explore some resources which will help us to test and secure our applications. Coming to OVAS, OVAS stands for Open Worldwide Application Security Project. It's an online community that produces free tools and resources in the field of web app security to test and secure our applications. Now, OVAS Top 10 is a list of top 10 frequent and critical security vulnerabilities in web applications. And the list is called OVAS Top 10. You can see the OVAS Top 10 vulnerabilities published in the year 2021 here. So, in the coming slide, we'll be going over each of these. Going back to the topic of our presentation, we'll be covering PyCode. PyCode is an initially vulnerable Python Django application. So, we can use PyCode to learn and exploit the OVAS Top 10 vulnerabilities. Thamin will walk us through the initial set of vulnerabilities. So, what do you think? So, thank you, others. So, now we can move to the integrated details of OVAS Top 10 and its demonstration using PyCode. So, the first one, broken access control. As you all know, access control enforces policies such that users cannot act outside their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all the data. So, the common access control vulnerabilities are bypassing access control checks by modifying URL, permitting view, or editing someone else's accounts by providing the unique identifier, and accessing API with missing access controls. So, now let's move to the demonstration by PyCode. So, here you can see that the user test is trying to log in as an admin. In the initial stage, the user can log in due to the invalid credentials, as you can see in the screen. So, by intercepting the request, we are adding an additional cookie admin and set it value to 1. Allow that test user to log in as an admin. By inspecting the code, so here we can see that the user is logged in as an admin successfully. And by inspecting the code, we can see that the source of truth is the request from the client side. So, for ensuring the access control, we need to sanitize these requests from the client side. So, these are a few steps to ensure access control. Except for public resources, they need all the permission by default. Implement access control mechanisms once and reuse them throughout the application. And log access control failures and let admins when there is a repeated failures. So, this is all about the first of us security. So, now we can move to the second vulnerability. It's called cryptographic failures. So, the first thing is to ensure the protection of data while in transit or in the rest stage. For example, the data like passwords, personal information, healthcare data, critical details, require additional protection and to be encrypted from the unauthorized users. So, the common cryptographic failures occurs when transmission of data as a plain text. Usage of outdated or weak cryptographic algorithms. And the received server certificate and the trust chain are not properly validated. So, usage of default cryptographies may lead to cryptographic failures. So, now let's check on private example. So, here you can see that due to a data breach, the attacker have the demo of the user table, which contains the encrypted password and the username. So, we can identify that the hash is 32 characters long and may come under a message digest family. I mean the MD family. By the help of online tools, we were able to identify that it's exactly belong to the MD5. And using MD5 decryptor, we were able to decrypt the password as admin1234. So, this is basically a cryptographic failure. So, a few prevention steps are store passwords using strong adaptive and salted hashing functions with a work factor, encrypt all the data in transit with secure protocols and disable caching for response that contains sensitive data and do not use the latest protocols FTP and SMTP for transporting sensitive data. So, this is all about the second one and now we can move to the third vulnerability, the injection. So, an application is vulnerable to attack when the user's supply data is not validated, filtered or sent from the back end. Dynamic queries or non-parameters calls without context are used to directly interrupt. So, some of the most common injection are SQL injection, no SQL, OIS command, and ORM injections. So, this, the concept is identical among all the individuals. So, let's have a look into the PyBot lab one. It's a demonstration of the SQL injection. So, by submitting the password field with the SQL injection query, we were able to successfully authenticate the user as an admin. So, let's have a quick look into the vulnerable code. We can clearly see that the code is dynamically accepting the values. And now let's have a look into the command line injection of the PyBot lab two. So, here we are able to successfully execute the command to get the current network configuration of the server by using the icon command. So, by inspecting the code similar to the SQL injection, we can see that the back end application is accepting the data from the client without the proper validation. So, here is a few methods to prevent the injection, both the SQL, no SQL, and ORM injections. So, usage of a safe API, which avoid using the interpreter end rule, that provides a parametrized interface for migrate to object relation tools, ORM tools, and proper server-side input validation. For dynamic queries, escape special character using the specific escape syntax for the interpreter, like in SQL or the ORM. So, this is all about the injection part. I know we can move to the fourth one, the insecure design. So, insecure design is a broad category representing different weakness expressed as a missing or ineffective control design. So, insecure design is not the source for all other top 10 risk categories. There's a difference between insecure design and insecure implementation. So, let's have a look into the PyBot example for a detailed overview. So, this is the PyBot lab objective. And so, this is the PyBot lab objective. And now, here, we can see that the website is offering a booking of movie tickets up to five tickets for a person for free. And the movie will be able to make public once all the tickets are sold. So, here, this is the screen where we were able to claim three tickets, up to five tickets. And here, we can see that 50 tickets are left. So, the system here, the system itself is safe, secure, but others are largely designed for. One can get all the tickets by creating multiple accounts. In this particular case, five tickets per page and a total of 60 records. So, we need to create 12 accounts only and claim five tickets from each. So, if the signup process is lame, then the processes can be automated. So, here, we need to have strong verification mechanism like KBC to be considered while developing these kind of applications. So, here's a few points to be noted to prevent the insecure design. Establish and use of library of secure design patterns. Use threat modeling for critical authentication, access control, business logic and key flows. Integrate security, language and control into user stories. And the finally write unit test cases and integration test cases to ensure the security. So, now, from the FI onwards, others will continue. Ranking fifth in the last problem list is security misconfiguration. An application might be vulnerable if it's missing security hardening. For example, it has improperly configured permission to access cloud resources. Also, it might be vulnerable if there are exposed open ports or pages without checks, etc. There might also be default credentials which may be left unchanged even in production environments. Ranking can also become a threat if stack traces or sensitive info is revealed to the end user when an error occurs. So, moving to the PyCode lab, we can see that a message only admin local port 8000 can access, your exhaust is not. The message is printed on a PyCode lab. So, by seeing this message, it seems like exhaust is an HTTP request header. The application is trying to authorize access by using a header value. So, we can use tools like Burbsuit. So, we can intercept request midway and modify and recent them. So, we can see that the action, this action is loading space, sending an HTTP request to the secret slash secret path. Now, to exploit the vulnerability, we are adding a new header named exhaust and setting its value to the desired one. So, on re-requesting again with this added header, we can access the secret from this page. Now, this case is an example of security through obscurity. That means an unknown header value is used to authorize access. So, in such cases, if the user is able to guess the header by any means, he or she will get an authorized access. So, to prevent these kind of errors, we should never trust raw inputs from the front end. Also, if you are using headers to impose access controls, the key should not be guessable or predictable. We should use an encryption mechanism to preserve the secrecy of the key. Now, moving on to the lab 2. Lab 2 home instructs as to look for a 500 error. So, this application have a vulnerability that the Django debug mode is enabled in this application. Now, let's try to open an invalid URL. So, when trying to open an invalid URL, we can see that all the valid URLs of the site are listed here. On the list, we can see a page called 500 error is present. When we are loading the 500 error page, there are multiple credentials. Traditionally, there are system metadata and other sensitive values like local variables or ENV variables and Django setting configurations are visible in this page. So, to mitigate the issue, when deploying to production of public environments, Django debug mode should be set to false and settings should be right. Now, some general tips to prevent security misconfiguration errors. These are a repeatable hardening process is needed to deploy apps to different environments. Also, unnecessary features or dependencies must be removed from the production applications. Then, we should periodically review and update configurations to secure values. For example, we should monitor cloud storage permissions such as H3 bucket permissions to make sure that proper access controls are imposed. Also, we should try to automate the security testing and vulnerability scanning process in all our environments including dev staging and production. Now, moving on to the next vulnerability, we have the usage of vulnerable and outdated components as A6 in the list. So, our application can be vulnerable if you are using insecure components and do not regularly track or patch our systems. Now, going to the lab or objective is to trigger a remote code execution vulnerability. So, the lab contains an application to convert YAML files to JSON file. We can upload YAML files and the server proceed to output the JSON. The app uses PyYAML library with the version 5.1 and the library is vulnerable to code execution. So, the vulnerability in this library is publicly disclosed and it was patched in the later releases. The exploit for this was released online and you can see a symbol YAML file which can exploit this vulnerability. So, here we are trying to run Python code and trying to print the RC exploit message. So, this is the PyGoat lab. Now, let's try to upload the specially crafted malicious YAML file. Now, we can see the output is none, but on checking the Django terminal output, we can see that on the run console, we can see the RC exploit message is printed. That means as an attacker, we can run arbitrary statements and we can run that in the server. So, this can be used for remote code execution and we can leak the credential of the application or we can try to gain access to the server. So, for mitigating similar issues, we should remove unnecessary dependencies and we should monitor the versions and security bulletins of libraries and the components we use. Also, we should also try to avoid supply chain attacks by verifying the integrity of the components and should only trust official sources to download packages. Next is A7, identification and authentication failures. There can be cases when the application handles passwords and logins incorrectly. This can let attackers access sensitive data. So, in the PyGoat lab of A7, our aim is to exploit the login without any functionality. The application is missing proper rate limiting. That means we can send bulk of requests without any errors and we'll be using this to gain unauthorized access. On opening the lab, we can see the login page of an admin. There is a login with OTP functionality and we'll be trying to exploit that. So, we need the email address of the admin. So, in the case of PyGoat, the email address is available in the source code file of this lab. Otherwise, we might need to recommend to find the mail ID of the admin or we can use similar patents to guess that. Now, for doing this attack, we'll be using OWASP SAP. We have previously used the verb suite. So, it's a tool for SAP is a tool developed by OWASP community and its open source. So, we can use SAP to intercept requests and perform attacks. So, I have just entered a random OTP. Here in this case, from the source code, we can see that the OTP, the possible OTP is three digits. So, we have to try all the three digits combinations of OTPs. Now, I have intercepted a sample request. So, it's sending a request to the path OTP and in the body of the request, we can see the OTP value is being sent. Now, I'm using a FASER tool of OWASP SAP. So, in the FASER tool, I am adding a variable in place of OTP and you can see I'm adding numbers from 100 to 999. All the possible three digits numbers. Then, on running the attack, you can see these are the results from the FASER. So, there are multiple responses. So, we can sort the result by size of the response body. So, we can see that there is one request with a different response body size and that's when the OTP value is 289. So, in that case, the response is logged in successfully as the user. So, in a realized scenario, we can use the cookie returned in this case. So, we tried all possible combinations of OTPs and for one OTP, we have obtained a successful login. So, in normal cases, on successful authentication, the server will send us a cookie and we can use that cookie for sending further requests as I did. Now, for mitigating these issues, we should implement multi-factor authentication whenever possible. Also, default credentials should be changed and proper password security measures should be implemented. Now, to prevent the issues as seen in the lab, we should enforce rate limits so that the attacker gets logged out after a fixed number of retries of unsuccessful login attempts. Next is A8, software and data integrity failures. So, these occur when app is not protected against integrity violations. For example, we can take insecure deserialization. Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker. So, we have earlier seen an example of such an example where we are trusting the cookies supplied by the user to gain unauthorized access. Now, moving to the lab, we can see a download page accepting name as an input from the user and it will supply a download link for the user. So, when inspecting the source, you can see that there is a download link, the download page was vulnerable to accesses. So, once we are using the access script from the attacker and we are passing that as a part of the URL parameter, so we can see that the JavaScript is executed in the page and we can see that the attacker provide file is being downloaded by the user. So, this can be sent to a genuine user of our website and trusting our domain, they will try to download the file and they will be redirected to download the attacker provided file. So, for the demonstrated vulnerability, accesses is used to redirect user to the malicious file. So, as a user, we should always verify the integrity of the files using checksums which are provided by the server. Now, for mitigating such issues, some general steps include usage of digital signature, verifying the trustworthiness of dependencies, and the supply chain, etc. Now, in the ninth position, we have security logging and monitoring failures. This category is to help detect, escalate, and respond to active breaches. Without logging and monitoring methodologies, application should not be able to detect threats in real time. So, an application should alert the development or security team during an active breach so that impacts of the attack can be minimized. So, this Pygote Lab consists of login page. So, each attempt to log in are logged to a file. We can see that the username of the users who are attempting logging are logged in this file. The vulnerability in this case is that any input in the username field is added to the log without any validation or categorization. So, this can lead to log overflow and attacker can repeatedly input large text in the field causing memory overflow. Also, any arbitrary string is logged without proper context of user action. So, an attacker can inject arbitrary logs which can confuse or mislead the developers who are viewing the logs. Here we have added a fake message in the log to upgrade Python. As well as we post, we added a large dummy text which was, which was written in the log file. So, for mitigating these issues, we need to ensure proper log management solutions are implemented and we might also need to ensure that log data provide enough context of the issue. Also, we should encode the log data to prevent injection attacks. Then proper monitoring and alerting system should be implemented to actively respond to an attack. Now, over to Thammin for covering the final vulnerability. So, here is the last vulnerability, SSRF, the server-side request forgery. SSRF, of course, occurs whenever an application is fetching a remote resource without validating the user-specific URL. It allows an attacker to force the application to send a crafter request to an expected behavior destination. So, even when the SSRF happens even when the application is protected by firewalls, VPN, or another type of network access control list. So, let's dig into the PyBot example. So, in this sample blog, we have buttons to navigate between posters. So, here you can see blog 1, blog 2, blog 3, and blog 4. So, on clicking each button, a post request is sent with a blog post URL as a variable. Let's click on any of the button and it will move to the specific blog. By intercepting the request, we can see that there is a blog parameter in the request. So, let's have a look into the vulnerable code. So, here the application is taking the ender file path from the client-side without a proper validation. That's the biggest issue here. So, the backup server is returning the file if it is present. Now, add an additional input field by inspecting the HTML content and set its value as views.py. We can add any project files, like here it is Django. So, for an example, we were added views.py. You can see it from the HTML inspector. So, yeah, by submitting this, I mean clicking the hidden field, we were able to retrieve all the information from the views.py. So, here is the vulnerability. So, we were able to retrieve all the files, all the file information from the backend. So, for mitigating this type of vulnerabilities, first of all, we need to sanitize all the input from the client-side. All the input data. And enforce a strict URL schema. And enforce partitioning the port and destination with a post-play alo list. And denote send a raw response to the front-end site. I mean the client-side as we do in this example. So, this is the code. We have applied the fixes for this vulnerability. So, instead of, you can see that instead of accepting the URL from the ender file path from the client-side, we have just accepting the URL slack. And, yeah, it will, and also we are filtering the file extension by .txt. It will, yeah, it will, yeah, it will resolve this vulnerability. So, this all about from our site. And we have almost covered all the top-10 hours security and its vulnerability exploitation using the PyGOT, the open-source repository. So, these are a few references we have referred the OS top-10 and PyGOT project demos. So, if you are interested in looking to learn more on this cybersecurity and Python security tools, you may look into these articles. So, that's all. And thank you, EuroPython team for giving such an opportunity to us. And thank you audience for listening us. So, here is the social handle. You may connect with all the social handles. So, once again, thank you. Thank you all.