What is Shield Security?

Shield Security is an Intrusion Detection and Prevention security plugin for WordPress that helps secure your website from malicious traffic. It has malicious traffic monitoring capability, Blocks spam bots and content, Disable anonymous REST API access, 2FA support, and many other features designed to keep your website safe and secure.

Key features and benefits

• Automatic IP Blocking: The website owner can check and set the offence count in the settings. After reaching the count, the website will automatically block all malicious traffic
• Site Traffic Monitoring: Continuously monitor all site activity and get security insights into your WordPress website in real time.
• Malware Scanner: The plugin scans your website for known malware and helps keep your website free from viruses. (pro feature)
• Brute Force and Spam Protection: SecureShield helps protect your website from brute force attacks by rate-limiting attempts and enforcing strong protection.
• Two-Factor Authentication: The plugin also offers two-factor authentication, an extra layer of security for admin user accounts.

You can learn more about the complete features of ShieldSecurity on their website.

Pre-Installation Steps

Before installing the ShieldSecurity WordPress plugin, taking a few pre-installation steps is important to ensure a smooth and safe process.

In this article, we will focus only on the free version of ShieldSecurity.

Backup your WordPress website

It’s always a good practice to create a backup of your WordPress website before installing any new plugins. This ensures that you can restore your website to its previous state in case anything goes wrong during installation.

Update WordPress and all plugins

Ensure your WordPress core installation and all other plugins are up to date. Running the latest versions of WordPress and plugins helps ensure compatibility and security.

Installing Shield Security Plugin

Log into your WordPress admin account, navigate to “Plugins” -> “Add Plugins”, and search for “Shield Security”.

Once you find the “Shield Security” plugin, click the “Install Now” button.

After installation, click the “Activate” button to enable the plugin.

Configure Shield Security

A plugin configuration wizard is loaded, which will quickly help you navigate and set up the required features.

1. A Shield Security menu will be displayed. Using the WordPress dashboard, you can Navigate to the Shield Security Plugin.
2. A Dedicated menu to manage all “Shield Security” plugin features.
3. Click on the “Next Step” to go ahead and quickly enable the security features needed.

Warning: Note the setup wizard options may change

Subscribing to Newsletter

The first step involves subscribing to a newsletter. You can sign up or click on “Next Step.”

Activate License:

The next step prompts activating the “ShieldPRO” license. As this article only focuses on the free version, I will skip it and click “Next Step.”

Choose a Initial Security Profile

If you’re a first-time user or just want a quick setup, the “Shield Security” plugin provides multiple profiles to choose from.

I recommend reviewing the options that each profile enables or disables before you select one. It’s often best to get started with the “Light” or “Medium” profile, as you can change this setting at any time.

Sometimes, stricter security features can conflict with or “break” other functionality on your site. Therefore, it’s safer to start with the “Light” or “Medium” profile, test your site to ensure everything works, and then move toward implementing a more robust security profile.

Setting up Shield Admin PIN

The application displays the form to set up a plugin PIN in the “Security Admin” section. This would be an added layer of protection for admins, ensuring only the authorized person can access or modify the security setting.

Key in the PIN, Confirm the PIN, and click on “Turn On Security Admin.” A message stating that the PIN has been successfully set will be displayed, and you will be taken to Bot Settings.

Bot Blocking

The next setting is about how to handle the Bots and Malicious traffic. Identifying the malicious traffic patterns and bad bot behaviour ruleset is already taken care of by the plugin vendor.

As a website owner, based on your site traffic and user patterns, decide after how many offences you would like to block the IP. The default offence limit is 10. I have set the offence limit to 5 for strict security and the Block duration to 1 week.

To activate it, click on “Set IP Blocking Options”. After 5 malicious attempts, the IP address will be blocked for 1 Week.

The Whitelist option is also available, where admins’ and security researchers’ IPs can be whitelisted as needed.

The option “Use CrowdSec Blocklists” is also an added benefit.

If an attacker’s IP is flagged on your site for offences, it is shared with CrowdSec, and similarly, other websites’ flagged IP addresses are shared with your site. This helps to block malicious attempts at early stages proactively.

Brute Force Login Protection

One of the most common attacks on a WordPress website is the automated Brute Force attack. The attacker tries to find the valid credentials that match a known user name or by blindly trying with a huge list of usernames and passwords. This happens continuously each and every day.

Shield Security Brute Force Login Protection will detect automated attacks and block them from exploitation.

Make sure to “Turn On - Protect my WordPress login from automated attacks”, click on “Set Login Protection”.

Sometimes, the admin may not be able to log in. Don’t forget to whitelist the admin IP address.

Block Spam Comments

Spam comments are another common problem among WordPress sites. The free version also covers this.

Please check on “Turn On - Block automated SPAM comments” and click on “Set Comment SPAM Protection” to enable.

Click “Go to Shield Overview” on the final thank you page.

Shield Security Dashboard

The “Security Overview” dashboard is a place where you can see all the info about security happenings on your site.

The top graph displays total number of Login Blocks, Bot Detection, Offenses, Connection Killed, IP Blocked etc in past 7 days. Additionally the security summary of our website.

One of the major reason I found to useful about this plugin compared to WordFence is for real-time threat protection and less memory usage compared to it.

Enable Auto Updates

Just make sure to enable the “auto-updates” for Shield Security plugin, so you don’t need to update every time manually. I have been using it for more than couple of years and haven’t see any breakages so far.

I hope the above information helps secure your site. The above configuration can quickly help to secure your WordPress site from good number of attacks. In future articles will be posting about the detailed hardening steps using Shield Security plugin soon.

Shield Security Help

Check out the Shield Security -Getting Started Guide for more help information.

Conclusion

Securing the WordPress website is an important factor for website owners. With the increasing attacks on WordPress, proactive measures like this help secure your online assets.

Secure Shield is a free, real-time WordPress security plugin that enhances your website’s security. It provides many features, such as blocking malicious comments, bots, attackers, firewall protection, and Two-Factor Authentication.

Don’t wait until it’s too late; enable it now to reduce security attacks.

Below are statistics on security vulnerabilities based on WordPress components by wpscan.

From the above screenshot, we can see that 94% of Vulnerabilities are found in WordPress plugins. Using nulled plugins is one among them. Nulled WordPress plugins/themes can expose your website to significant security risks and vulnerabilities.

This article will provide a comprehensive understanding of what nulled plugins and themes are, their security risks, the alternatives, when you can use them, etc.

📖 What are Nulled Plugins and Nulled Themes?

A Nulled plugin is a modified version of open-source or premium WordPress plugins distributed for free or at a negligible cost over the Internet through unofficial channels that anyone can download and use.

Security threats apply to both WordPress plugins and themes.

For premium plugins, the original code is altered, and all license limitations will be nullified, so you can freely use all the premium capabilities without paying any extra money.

In the case of open-source plugins, additional features not part of the official plugin are added to attract users to download and use.

🧲 Why are nulled plugins/themes so attractive?

The WordPress ecosystem is a huge market, and you might need to decide which plugin suits your requirements. Most free plugins are good for getting started, but as you progress, you might see limitations and require additional features.

The above requirements might make you consider premium plugins an option. But again, you might need to get a premium plugin for a theme, a premium plugin for forms, etc., as the requirements keep going.

Considering the Hosting, Plugins, Themes, Development, Official Support, etc. It might look expensive, and as humans, we normally look for ways to cut costs or get discounts.

Cost Effective:

Nulled plugins sound like a good deal for small website owners who want to get their site up and running without spending a lot of money.

Selected Features

• Users might need only a few essential features rather than paying for all options.

One Subscription - Access to Many Premium Plugins

• There are a few unofficial sources on the internet, where you can pay once and access multiple premium nulled plugins without paying individually for each plugin.

Challenging Experiences

• Users might have faced frustrating experiences with unresponsive support.
• Issues due to account lockouts or inability to register valid user accounts.
• License activation problems, payment-related issues, etc.

Assumed Time Saving

• Used might believe it can cut the development efforts and build the website faster.

Overall, Nulled plugins might seem like a good deal for free, but remember they may contain malware, a backdoor or other security vulnerabilities bundled inside them, which can harm your website with various security threats.

🔓 Security Threats Associated with Nulled Plugins

In this section will dig further and understand the security risks associated with the nulled plugins:

Outdated Security Patches

Official plugin developers patch security loopholes when they receive them. You will miss the patching updates. Missing security patches can leave your website unprotected, and attackers use this opportunity to compromise the site with known security vulnerabilities.

Malicious Code Injection

One of the major threats associated with nulled WordPress plugins or themes is the possibility of injecting malware inside the code.

• Backdoor Access: The malicious code is injected and can silently provide access to your website for attackers. Attackers can use it to execute Remote Code Execution (RCE) and completely control your website.

The single most common type of backdoor belonged to a PHP backdoor uploader found on 8.68% of remediated websites, while the most persistent backdoor (removed from more than 180,000 files last year) was WordPress specific and concealed within nulled themes. Its ability to self-replicate once it has established a footprint and layers of obfuscation makes it especially challenging to pinpoint and remove.

From Sucuri - Hacked Website Report

• Open Redirection Attack (Redirection Hack): Whenever users visit your website, the injected code redirects them to a malicious website, with or without clicking any link. This is called an open-redirection attack.
• Ransomware Attack: The malicious code injected inside the application will encrypt all files on the server and/or database. To regain access to those encrypted files, you must pay the attacker a ransom to obtain the decryption key.
• Spread Virus: Infected sites can spread the virus as well, and some advanced malware can even self-replicate and use your site as a medium to compromise other systems.
• Denial of Service (DOS) Attacks: The infected website can be used by attackers to launch a denial-of-service attack against other sites, which can even lead to blacklisting or marking your domain as spam. etc.

Data Breach

Another major issue with the nulled plugin is the theft of your website data. An attacker might steal sensitive information such as usernames, passwords, payment-related details (if you are using e-commerce), etc.

• Data Breaches can cost you a lot when you need to deal with legal consequences and damages. This would also impact your business reputation and trust.
• Sometimes, it can also lead to privacy issues. Malware can silently harvest your users’ data and sell it to third-party vendors.

🛡️ Case Study - Criyasoft

Criyasoft is one of the client’s educational websites. It is used to demonstrate the functionalities development in WordPress and is always kept online for students’ reference.

Recently, it became the victim of an open-redirection attack. After 4 levels of redirections, it will take genuine users to a casino website.

What is the Impact?

The “About” page link is tampered with, and whenever a visitor clicks it, it will redirected multiple times and take the user to a casino website

What is the root cause?

After analyzing the site, I found a couple of main reasons, which are listed below.

Outdated Plugins and Themes - Both plugins and themes are not updated regularly.

During the initial analysis, I discovered that it was just an ad-tracking link or that it was due to outdated plugins that have known security vulnerabilities. Updated all the plugins and themes. Ensured all was fixed, as it was no longer reproducible.

After a few days, the attack pattern started to repeat again, and once it started impacting other page links, I realized it was some malicious behaviour impacting navigating menu links.

After thoroughly evaluating each installed plugin and theme, I discovered that the client installed one of the nulled plugins for quick educational purposes instead of purchasing one that contained malicious code.

Novashare nulled plugin is used - A nulled WordPress social share plugin is being used.

After cleaning up the nulled plugin files, the site is back to normal, with continuous security monitoring enabled to prevent further attacks.

How was it fixed?

I scanned it with malware-scanning plugins to find the root cause. (Used Malcare)

Post confirmation removed the Novoshare nulled plugin completely, deleted all its files and updated all the themes and plugins. Additional enabled “auto-updates” for all non-customized plugins and themes.

Lastly, I configured the free “ShieldSecurity” plugin to monitor real-time security alerts and prevent them from further impacting the website.

⛔ Additional Reasons to Avoid Nulled Plugins?

Below are some additional trust concerns you might consider before using any of the nulled plugins. We don’t know what is inside the code, and we need to be prepared for any unexpected behaviours that can cause the site to crash or impact its availability.

Flagged by Search Engines - Google

If Google finds any malicious behaviour on your website, an additional flag is displayed below your domain with the message “This site may be hacked.” This indicates that users should avoid visiting the Website as malicious activity has been spotted.

If you believe you are a victim, check out Google’s hacked site guide for fixing.

Recovering from Nulled WordPress Plugin Damage

Restoring your website after discovering it is hacked or causing unexpected behaviour is more time-consuming.

• Restore Backup: Maintaining regular backups can help you quickly restore the existing snapshots by identifying the impacted behaviour early.

• Scanning for Malware or Seeking Professional Assistance: For hacked websites, it’s possible to mitigate the damage and regain control. You need to set up malware scanning solutions to identify infected files like “Sucuri”, “WordFence”, “Malcare”, etc. Additionally, don’t hesitate to seek professional assistance if required.

• Time-Consuming: As mentioned earlier, using nulled WordPress plugins or themes might seem time-saving, but damage control requires a lot more time and resources to restore the website to normal.

  ⚠️Remember, official authors or vendors don’t support nulled plugins. Even if they would like to offer, they might have limited knowledge.

I hope the above information can help you to decide and take respective action with respective to Nulled WordPress plugins or themes.

👍 Best place for Plugins and Themes

Finding safe and reliable WordPress plugins is easy. There are many free and paid premium options for securely accessing your website.

• WordPress Plugins - All WordPress Plugins Directory

• WordPress Themes - All WordPress Themes Directory

Additional Tips

• For each WordPress plugin or theme, check their reviews or visit its home page, and ensure you are purchasing only from official authors' sites.

• EnvatoElements - Another common place where you can find WordPlugins and Themes.

🤔 Still Using Nulled Plugins?

If you use nulled plugins on production websites, the transition steps below will be helpful, as they can still pose security risks.

Scan for known Vulnerabilities or Malware

Antivirus and antimalware companies work around the clock to find new malware behaviours and patterns and update their signatures database.

You can leverage the free online malware scans such as “Sucuri”,"WordFence", “Malcare”, “VirusTotal”, etc., to check the nulled plugins if it does do contain malware.

You could also check out [[./wordpress-scan-for-vulnerabilities-a-comprehensive-guide-for-site-security.org][WordPress Scan for Vulnerabilities a comprehensive guide for site security]] to learn more about scanning your WordPress site for vulnerabilities.

Once you are confident that no malicious patterns are found, proceed with the next steps of the transition. If any are found, make sure to clean up before proceeding.

Transition to Free or Premium Plugins:

Transitioning away from nulled plugins is crucial for maintaining the security and integrity of your WordPress site. The below steps can help you ensure a smooth migration to premium or free plugins with minimal disruption.

• Backup Your Website: Ensure complete site backup is taken to prevent potential data loss.
• Test and Validate alternate plugins: Ensure all features and functionalities work as intended with the new plugins.
• Remove Nulled Plugins: After successfully evaluating new plugins, safely remove the nulled plugins from your website, eliminating any potential security risks associated with their usage.
• Publish Changes: Push all the updated changes into the production environment and ensure that all the functionalities are working as expected.

📝 Conclusion

The WordPress nulled plugins or themes might seem an attractive alternative to paying for premium features, but it’s critical to weigh the security risks associated with their use. The potential harm they can cause to your website security is more, including reputational damage, a drop in your site rankings, a decrease in revenue, etc. Opting for free or trial versions and ensuring all the plugins and themes are up-to-date can minimize security threats.

🙋 FAQs

What are nulled WordPress Plugins?

A Nulled plugin is a modified version of open-source or premium WordPress plugins distributed for free or at a negligible cost over the Internet through unofficial channels that anyone can download and use.

Are nulled plugins safe to use?

No, and It should never be installed in production environments.

What are the security risks associated with using nulled plugins?

It can be used as a medium for injecting and spreading malware and exploiting your website with known security vulnerabilities. It may also lead to data theft.

How can I avoid using nulled plugins?

Download and install plugins from reputed sources like the WordPress plugin directory and trusted marketplaces.

🔗 Additional References:

• Why You Should Stop Using Nulled WordPress Themes and Plugins
• Why you should avoid using Nulled WordPress themes and plugins

The major focus of this article is to provide detailed and step-by-step instructions to help website owners take action with easy-to-follow steps. Even non-technical users would also be able to follow along and secure your WordPress sites.

Understanding the Importance of WordPress Security

It is reasonable for users to think that WordPress’s security must be taken care of by the provider itself. Let’s understand how the WordPress ecosystem works.

About WordPress Software

WordPress is a dynamic open-source content management system that is freely available to anyone who wants to set up a publishing website.

The WordPress core is continuously hardened with all the vulnerabilities that have been identified and reported as part of OWASP Top 10. Also, the recommended security best practices are provided for authors developing third-party plugins and themes.

The WordPress Team’s responsibility covers identifying and resolving the security issues in the core software provided. It’s a community project that is used across 10 million websites on the internet. Any programmer can create a third-party plugin or theme based on their needs.

From above, even after providing the secure guidelines and getting the code reviewed by volunteers, sometimes the security bugs can be missed, or new bugs found need to be updated accordingly.

To proactively mitigate security vulnerabilities before attackers find them, the WordPress Security team even runs the Bug Bounty program at HackerOne as an additional measure to report any security vulnerabilities identified by security researchers and make the platform more secure.

WordPress security teams even go beyond to remove the vulnerable plugin from the directory if the plugin owner doesn’t fix or fix it themself in extreme cases.

Third-party plugins and themes are reviewed for security to a certain extent. In addition to WordPress software, the security of the underlying operating system used, configurations, database servers, secure file transfers, TLS security, and web servers are also equally important.

The WordPress team is actively working on mitigating security defects in WordPress Core, Plugins, and Themes. However, the security of all underlying technologies and ensuring all the updates are patched falls under the Owner’s responsibility.

If your hosting provider takes care of your underlying tech stack, it is your responsibility to ensure the core, themes, and plugins are updated and downloaded from recommended websites.

About Managed WordPress

When you come to Managed WordPress (i.e., wordpress.com), You just need to register, pay according to your package preference, and start publishing right away.

Managed WordPress uses the same WordPress Core Software. The underlying technology, like setting up software and managing the web server and other resources, is completely handled by the Automattic team.

Authors need to focus only on creating content for their niche.

The Vital Need for Security

Based on the above choices, the security requirements do vary. A managed service is the best option for most website owners and companies. However, there are cases where the website owners require more customizability or manage multiple websites. In those cases, the users prefer the self-hosted version of WordPress.

Going forward, we will focus only on the security needs of self-hosted WordPress websites. We will set up a WordPress site and start securing it step by step.

Cybercriminals are constantly looking for new ways to exploit vulnerabilities and compromise website security. Any security weakness on site can be an opportunity for attackers. As a WordPress website owner, securing the business and customer data hosted on your website is the most crucial.

Sucuri ranked WordPress as the most infected CMS website in 2022 by Sucuri. Below are statistics on vulnerabilities based on WordPress components by wpscan.

Most of the vulnerabilities were found in third-party plugins, and a few of them are in the themes. Attackers leverage these vulnerabilities to gain unauthorized access to your website, spread malware, steal sensitive information, or even disrupt the functionality of your site. As a result, proactive efforts can help you to secure your website.

Defense in Depth: Security is always about minimizing the risks by adding as many layers of protection as possible. It’s more of a risk-reduction strategy.

Both technical and non-technical users can follow the content covered in this article.

If, by any chance, you are using another third-party vendor to manage “WordPress” for you? check out their support page to understand what is covered in terms of security and what needs to be taken care of by yourself.

Backup your WordPress site

Before making any changes to your website, the first thing to do is to ensure that a complete website backup is taken and can be easily restored at any time. This precautionary measure will be helpful in case any unexpected issues arise. Therefore, data integrity should never be compromised.

🚧 The backup copy should always be placed in a separate location, different from the one where you have hosted your WordPress website.

It would be a disaster if you lost the backup copy and all the site contents were tampered with or completely lost in any security attack.

Having Scheduled Backup

On-demand backups are a good thing to have. However, having a scheduled backup is still crucial for a website.

Taking backups at regular intervals can help you restore in case of a security incident or from human mistakes. You can set the frequency based on how much new data is being added to your site.

You can adjust the backup intervals from minutes to days based on the criticality of the data. This is one of the important things to check while choosing a hosting provider.

Check about how to back up your WordPress site by Syed Balkhi.

Keeping WordPress core, Themes, and Plugins updated

One of the most essential steps is to keep your site updated with the latest version of WordPress core, theme, and plugins being used.

Outdated plugins can always pose security risks. From the above stats, we can understand that 94% of the attacks originated from third-party plugins. Keeping the site updated can help you to prevent a lot of attacks. This simple step can mitigate a lot of attacks for you.

Log into your WordPress site using an admin account and navigate to the “Dashboard” - “Updates”.

On your updates dashboard, you should be able to see information about which things require updates.

• Currently, our WordPress Core is already updated, and the latest version is present on the server, i.e., Version 6.4.3.
• The 5 Plugins installed on the above server require updating. The updates can be for many reasons, like new feature releases or bug fixes. You can always click on the “View version x.x.x details” link, which will take you to the Changelog, where a detailed list of what has been changed and what has been improved.
• WordPress Core is Automatically updated with security releases.

An Admin can see all the available updates.

The “Updates” section of the WordPress dashboard contains information about all the updates needed for your website, such as the WordPress core, plugins, and themes.

You can easily update all the necessary plugins.

❗Points to Remember

1. Ensure all your Custom Coded application functionality is free from conflicts.
2. Verify all Plugins, Themes, and Core are compatible with the versions and tech stack you are using.

Enable auto-updates for WordPress Plugins and Themes

Navigate to the “Plugins” section in the dashboard, which will be displayed below.

The “Plugins” page is where you can manage all your plugins and update them all at once.

For any plugins that you think are not very impactful to your website, you can click on the “Enable auto-updates” button. It will check for the latest updates available daily. If yes, it will automatically update for you.

The above option is very helpful.

Default themes provided by WordPress are rigorously tested for security vulnerabilities along with the core.

Similarly, navigate to “Appearance” -> “Theme”, select the theme, and click on “Theme Details” for the one that you are using.

You can manually update or just click on the “Enable auto-updates” link. I hope you’re just using the default team directly provided by the vendor without any customization.

Deactivate Unnecessary or Unused Plugins came default

When we spin up a self-hosted WordPress website, we usually use prebuilt templates provided by the cloud providers or the hosting providers. In any of those cases, WordPress does come with some pre-installed plugins, but some of them might not be useful in most cases. You can just deactivate those plugins or delete them completely if they are not of much help.

Navigate to the “Plugins” section in the dashboard, select the “Active” plugins list, and click on the “Deactivate” link for all the plugins that are not very useful to you.

Even after the plugin is deactivated, the code is still present and using your storage place on the disk. The database entries will be there.

If the plugin does not have any important data, you can go ahead and delete it. It will delete all the files and data related to it from the database as well.

Warning: Avoid the below step if you haven’t backed up your data. Backups can help you to restore if needed.

If you think the plugin is no longer needed, You can go ahead and delete it completely. Click on the “Inactive” filter from the “Plugins” dashboard and click “Delete”.

The above step is one of the ways in which you can reduce the attack surface for your website. Not only that, but this step can also increase the performance of your website.

Delete Unused Themes came by default

You can keep the unused theme if you are using it for testing or for other purposes. But I believe there is no point in maintaining a feature that we don’t use.

Navigate to “Appearance” -> “Theme,” select the theme, and click on “Theme Details” for the one that you are using.

At the bottom of the Theme Details, you can just click on the “Delete” button.

Qualities to Check with Your Hosting Provider

• The vendor provides the most recent stable version of WordPress Core and the latest version of all underlying tech stack.
• Providing reliable methods for backup and recovery of your data as and when needed.
• Ensuring secure communication between the Client and the Server. (Ex:TLS)
• Transparency in communications in case of any security incidents.
• Ensuring your site availability.
• Ability to discuss any of your security concerns with the support team.

🖥️ Website owners must take care of the above in the case of a self-managed site.

Use HTTPS Secure Communication Protocol

Ensure your WordPress website is enabled with Transport Layer Security (TLS), i.e., HTTPS enabled. Older versions are referred to as SSL.

• HTTPS runs on port 443 by default. (You can change it to any port.)
• HTTP runs on port 80 by default.

One of the major drawbacks of the HTTP protocol is that anyone on your network can view and monitor all your activity, including sensitive information like usernames, passwords, etc.

HTTPS prevents attackers from viewing or tampering with Client-Server communication. It transmits and receives all your communications through a secure channel.

Ensure HTTPS is enabled and that your site only listens to HTTPS communications. To verify, navigate to the WordPress Dashboard –> Settings –> General.

Check that the WordPress Address (URL) and Site Address (URL) are set with the https prefix as displayed below.

If you are unable to update it from the portal, you might need to change it accordingly in the wp-config.php configuration file.

Additionally, you can go ahead and add a rule in the firewall to disable all communications on HTTP port 80 and redirect all traffic to HTTPS port 443.

Let’s verify our site is accessible over HTTPS and has a valid certificate.

Sometimes, the vendor might already have enabled it or provided you with the necessary information to do so. Refer to your vendor documentation for instructions on how to do so.

Using WordPress Security Plugins

The built-in options for securing the WordPress site are limited. This is where third-party plugins and SASE-based firewalls come to our rescue. In this section, I will focus only on one WordPress security plugin, which contains more options available and is freely available.

I will use Wordfence for the examples below. There is no silver bullet in security. You are free to explore other alternative plugins, both free and paid, listed below.

• Shield Security
• Sucuri
• All-In-One Security
• Solid Security
• others

Pick one that aligns closely with your requirements. Remember, Trust and reliability are the most important factors when choosing a security plugin. Check out their reviews and support information, too.

Why did I choose Wordfence?

• A good number of security hardening features are available for free, which can help you quickly start securing your website.
• Offers malware scanning for free.

❗The malware scanning rules are updated monthly in a free version, and Real-time protection is available in a premium version.

• It continuously updates the vulnerabilities database.

Wordfence Installation

Ensure Wordfence Wordpress plugin is installed and configured. Continue to the next section if you have already installed it.

Admin Login: Enable Two-Factor Authentication

The first step is to secure the WordPress site’s logging-in mechanism. This will ensure only authorized users are logged into the portal and deny all others by default.

This is not limited to the admin user account. It can be enabled for all the user accounts and roles that are critical for your business operations.

To get started, Log into the WordPress admin dashboard.

1. On the left side of the WordPress admin menu, click on “Wordfence”.
2. Navigate to “Login Security”.
3. Wordfence “Two-Factor Authentication (2FA)” screen will be loaded with instructions for setting up the 2FA.

The 2FA provided here is based on a mobile application. You can register with any of the Time-based One-time Password (TOTP) apps, such as Google Authenticator, FreeOTP, Authy. Enter the TOTP code displayed on your Mobile app and verify if it’s reflecting correctly and syncing properly with the server., etc. Full list of supported apps can be referred here.

1. In the above screenshot, “user” is my admin account, and I will enable 2FA for it.
2. Using any one of the TOTP-based apps, scan the code and ensure the entry is added to your 2FA app.
3. After adding an entry, download and save the Recovery Codes in a safe location, which can be used when the TOTP code is unavailable.
4. Enter the TOTP code displayed on your mobile app to verify that it’s reflecting correctly and syncing properly with the server.
5. Click on the “Activate” button to ensure your 2FA is added successfully.

I hope you have saved your recovery codes safely. After adding 2FA to your admin account, the next screen will be displayed about your 2FA status.

1. Displays information about the Two-Factor Authentication.
2. 2FA status of the currently logged-in user. (i.e., user).
3. Option to deactivate.
4. If your recovery codes are compromised or lost, or if you used all the previous codes, you can generate a new set of recovery codes by clicking on “Generate New Codes”.

1. Verifying Two-Factor Authentication

   Let’s go ahead and verify the 2FA which we have newly created. Launch a new incognito window and visit your WordPress admin login page.

   A login window appears, the same as how you used to log in earlier. Just enter the valid admin username and password. Immediately, you will be taken to a 2FA authentication page.

   

   Enter the code from your mobile app for the wordfence and ensure everything works successfully. This will confirm that you have successfully set up your 2FA authentication for your admin account.

Updating 2FA Settings

1. In the WordPress dashboard, visit “Wordfence” -> “Login Security” and click on the “Settings” tab.

1. You can view the summary of user accounts and update the 2FA policy for your WordPress Portal. I have chosen all the admin accounts that must have 2FA enabled and are optional for other users.

Enable 2FA for WooCommerce

If you are using WooCommerce, ensure that the 2FA support is extended to WooCommerce users as well.

Enable reCaptcha

In the Wordfence “Login Security” settings, you can even find the option to enable “reCaptcha”, which verifies it is a human who is trying to log in or register before submitting.

This will help you in defending from brute-force attacks.

1. Ensure reCaptcha is checked, and make sure to update the Site Key and secret provided from your Google account after registering. You can register for reCaptcha by logging in with your Google account here.
2. This is a threshold, which is like how strictly you want to check whether it’s a human or a bot. It’s good to start with the default. 1.0 is considered stricter, and 0.0 is the least strict.

Please also consider user convenience. Perform strict checks based on the criticality of the data you are dealing with.

1. Verify reCaptcha

   Once Google reCaptcha is enabled, you will see the captcha icon at the bottom of the WordPress admin login page and user registration page.

   f

   From now on, it will verify and ensure that only humans can fill out and submit the forms on your website.

   

   Remember, google reCaptcha has a limit on the number of free assessments that can be done. Beyond the limit, it will be charged monthly.

   Using the above settings, you can prevent the brute-force attacks on your website.

Strengthen Wordfence Firewall Settings

Imagine if any of the user accounts on the website used a weak password or a guessable password from a dictionary. It would be easy for attackers to brute-force the password and take over the account.

This is one of the common attacks in WordPress, and you might continuously see the BruteForce attempts on your website.

2FA login security can prevent attacks to an extent, but how about non-2FA login accounts?

Let’s go ahead and tighten the security for those accounts as well.

Enforce a Strong Password Policy

In the WordPress admin dashboard, navigate to “Wordfence”, and select “All Options” from the left side menu.

The Wordfence “All Options” page will be loaded as displayed below.

Click and Expand the “Brute Force Protection” section.

1. Ensure the “Brute Force Protection” is enabled.
2. Scroll down to the “Additional Options” section and ensure the “Enforce Strong passwords” option is checked.
3. Set it to “Force all members to use strong passwords” from the dropdown menu.
4. Make sure to click on “Save Changes”.

These options would be enabled by default in Wordfence. It’s good to verify. Going ahead, Wordfence will ensure that all user accounts are set with strong passwords.

Enforcing Account Lockout - Limiting Login Attempts

On the same page, we can even update the Account Lockout policy settings as well.

The Account Lockout settings provided by the default Wordfence are a good limit. You can proceed with it.

If your site is receiving a high number of brute force attacks, you can improve the lockout policy, as I have updated it on my website.

Additionally, I have selected the option to “Prevent the use of passwords from leaked in data breaches”, which prevents the admin from using the leaked passwords.

Do not lock yourself out from the WordPress portal.

Wordfence Firewall - IP Whitelist

To prevent yourself from locking out from the WordPress portal, it is good to whitelist your IP address.

1. Click on Wordfence in the WordPress admin dashboard.
2. Select “All Options” to list all the Wordfence options available.
3. The application loads the “All Options” page. Click and Expand “Advanced Firewall Options”.
4. In the Allowed IP address that bypass all rules, enter your Public IP address.
5. Click on “Save Changes” to ensure the changes are persistent.

Using the above option, you can ensure that you are not locking out yourself. The same option can be used to whitelist the security audits as well.

Ensure Web Application Firewall Enabled

Using a firewall is one way to control what traffic must be allowed and what needs to be blocked from reaching your website. Web Application Firewalls (WAFs) can filter out suspicious traffic coming from the internet.

These WAFs are continuously updated with the patterns used by the attackers to compromise the website, which is called as rulesets.

This feature is also available in the Wordfence plugin. The free version of the Wordfence plugin will check and stop complex threats.

It is important to regularly update and review your firewall settings to ensure that your website’s security remains strong and up-to-date.

The Wordfence dashboard provides you with the information you need about firewall settings and alerts as well.

1. Logging into the WordPress admin account, click on the “Wordfence” plugin on the left side.
2. Click on the “Firewall” link on the left-side menu.
3. The “Wordfence Dashboard” will be loaded as displayed in the above screenshot.
4. Click on the “Manage Firewall” to check out all its settings and options.

The firewall options page will be loaded and displayed below.

From the above screenshot, you can understand that the community edition (i.e. the free version) stops the complex attacks, and its ruleset updates are delayed for 30 days compared to premium editions.

1. Click and expand the “Basic Firewall Options”
2. When you set up the “Wordfence” plugin, it starts with a “Learning Mode”. In this mode, it tries to understand your plugins and themes' working behaviour, like how they work and what is expected behaviour.

Post learning mode, it will automatically switch to “Enabled and Protecting” mode. You could also change it by clicking on the drop-down menu.

On the same page, click-expand on the “Advanced Firewall Options” and scroll down, you would be able to see firewall rules enabled on your website.

These are the rule sets that check for attack patterns for web application vulnerabilities like XSS, SQLI, File upload, XXE, etc.

If an attacker tries to exploit your website with an XSS vulnerability, the Firewall’s XSS rule is triggered, and that particular attempt is blocked immediately.

Let’s check the Wordfence Firewall in Action. I will just key in with a sample XSS payload, and let’s see how it behaves.

The above screenshot demonstrates that our firewall is active and blocking the XSS attempts with an HTTP response Forbidden 403 and a custom warning message from the Wordfence plugin.

If you have authorized any security professional to carry out the security assessment on your website, whitelist the IP address of authorized professionals and remove it when the assessment is complete.

I hope the above options can help you get started. At any point, you could opt for a premium service or seek professional assistance when needed.

Avoid Nulled WordPress Plugins or Themes

WordPress Nulled plugins or themes are modified versions of premium WordPress plugins distributed for free or at a negligible cost over the Internet through unofficial channels that anyone can download and use.

It might seem like a good deal to use without paying, but it does come with a few security risks. To learn more about it, check out the below bookmark.

Security Threats of Nulled WordPress Plugins and Themes

Wordfence Help

All the options I have covered above are good for helping you easily get started securing your WordPress website.

Wordfence Help Center

Using Cloudflare Web Application Firewall

Sometimes, the website owner would like to avoid having too many plugins for multiple reasons, such as slowdowns or maintenance reasons.

In this case, we could opt for a cloud-based web application firewall like Cloudflare WAF, Amazon WAF, etc. These cloud-based firewalls act as proxies, monitor traffic and filter out all malicious traffic before passing it to our Web Server. Since everything is done on the cloud, your server is not overloaded.

These cloud-based firewalls act as the first line of defence and filter out OWASP Top 10 Vulnerabilities, Bot Protection, Block DDOS attacks, and malicious behaviour before allowing traffic to your server. Cloudflare has free and premium plans. The rest are premium services.

For the demo, we shall get started using the free option that is available. Before proceeding, I would request you to check the following link, Adding a Site to Cloudflare, and ensure your website is added to Cloudflare.

Log into your Cloudflare account, navigate to your DNS settings and click on Records.

In your DNS records, look out for the one pointing to your WordPress website. In my case it “wp.securityarray.io”.

1. Click “Edit” on your DNS record. i.e. for wp.securityarray.io
2. Ensure the “Proxy Status” is enabled and all your incoming traffic is proxied through Cloudflare.
3. Click on the “Save” button to make the changes.

Additionally, Cloudflare also hides your server IP address from the public and has basic WAF protection, CDN capabilities, and DDOS protection enabled for your website.

The above configuration will ensure that all our traffic for “wp.securityarray.io” hits Cloudflare first and then reaches my server.

With the above, we have successfully been able to set up the basic WAF protection for our website.

As of today, a cheaper option for WordPress users is to use Cloudflare through Cloudways. Cloudways + Cloudflare are integrated and offer premium WAF capabilities at lower cost.

Scan for Vulnerabilities and Malware

Another important aspect of WordPress security is to scan your website for any known vulnerabilities and Malware at regular intervals.

Initially, would recommend installing and getting started with a Jetpack Protect plugin. I

The Jetpack Protect plugin differs from the Jetpack plugin and is offered separately by the Jetpack team. It is important to note that there is no dependency between the Jetpack Protect plugin and the Jetpack plugin.

The next steps would be to evaluate the different security plugins that are available in the market and choose the one that meets your requirements and needs.

Check out the bookmark below to learn more about the different ways to scan your WordPress website for vulnerabilities.

WordPress Scan for Vulnerabilities

Install only reputable and trusted plugins. I recommend checking the plugins’ reviews and support information before choosing one.

Monitoring and Responding to Security Threats

A good amount of context is covered in securing the WordPress website. Hardening the WordPress Site is not a one-time effort.

You would need to dedicate some time to monitoring it continuously, whether daily, weekly, or monthly, based on the severity of the data you are handling.

“Security is a process, not a product.” By: Bruce Schneier

Advantages of Monitoring

• Helps to keep your WebSite free from malware
• You know about the latest threats and keeping the WordPress core and plugins updated.
• Recognize the breaches early.
• You could also opt for updates through email notifications.

Wordfence Scan

A good amount of monitoring for security threats can be done with the help of the Wordfence plugin itself.

1. In the WordPress admin dashboard, click and select “Wordfence”
2. Click on the “Scan” link.
3. The “Scan” section will loaded and displayed as shown above.
4. You can start the scan by clicking on the “Start New Scan” button at any time on demand. It is generally scheduled to run every 24 hours. For more information, click on “Scan Options and Scheduling”.
5. Wordfence Scan will check for the Server State, File Changes, Malware Scan, Content Safety, Public Files, Password Strength, Vulnerability Scan, and User & Option Audit related files. Additionally, it will display warnings if any are found on your website.
6. Results information will be displayed.

Just double-click on the result item or click on the details button on the result. It will provide you with more information.

For each result, you can understand the problem and how to address it. If you think any of the result is “Fase Positive”, you can click on the Ignore button.

Performing all the above actions can help you reduce attacks and secure the website to a good extent. You can always seek professional services if additional needs arise.

Troubleshooting

My Website becomes slow when using Wordfence

This is one of the performance impacts that can be witnessed on some of the WordPress websites. One option is to set “Low resource scanning”.

To do this, Navigate to “Wordfence” -> “Scan” -> Scanner Options and Scheduling -> Performance Option -> Ensure “Use low resource scanning (reduces server load by lengthening the scan duration)” is enabled and check.

Another option could be to use premium solutions like Sucuri or check Cloudflare WAF solutions.

I think my website has been Hacked.

Try using a couple of options, like cleaning and reinstalling all the latest versions of the plugins. Scan with malware analysis plugins like Wordfence, Sucuri, etc. If the issue persists, seek professional assistance.

Conclusion

In conclusion, website security is of utmost importance, especially for WordPress website owners. With the increasing number of cyber threats, it’s crucial to take proactive measures to protect your online assets.

Wordfence is a security plugin that is freely available for WordPress and provides a wide range of features to enhance your website’s security. Free plugins always come with limitations. It is good to get started, but when demand increases, you might need to opt for premium options with dedicated support.

By following the steps outlined in this guide, you can configure Wordfence and its settings to keep your website safe from potential threats such as malware, brute force attacks, and more.

Additionally, keep monitoring the WordPress security news and take action accordingly. Don’t wait until it’s too late – take the necessary steps to secure your website today.

Additional Checklists and References:

• WordPress Security
• JetPack - The Only WordPress Security Checklist
• The Ultimate WordPress Security Checklist
• The Ultimate WordPress Security Checklist - Cloudways

Let’s start by setting up the lab environment needed for practicing XSS, and upcoming articles will cover the theory and step-by-step approach for identifying the vulnerability.

Kurukshetra- An XSS-vulnerable app by design

In the author’s own words, “Kurukshetra is a vulnerable lab geared towards practicing XSS challenges.”

The app’s motto is to give you hands-on experience in identifying the XSS vulnerability in different ways and also keep you updated about the theory and basics needed.

Check out the GitHub - D4rk36/Kurukshetra for more info.

All the content here provided is only for the educational purposes. Authors, Application Creators or Web Site Owners are not responsible for misuse of your knowledge. You are responsible for your own actions!.

Kurukshetra app isn’t for production use! Only for testing and learning on a host machine.

Preparing Environment

A couple of things must be done to start working on the “Kurukshetra” XSS vulnerable application.

1. Docker & Docker Compose must be installed and working
2. A working OS(Linux/Windows/Mac) with network connectivity
3. Git installed

Feel free to skip to the next section if all the required tools are pre-installed.

For users whose Docker is not installed, please visit the Get Docker page and follow the instructions as specified.

Once installed, make sure the Docker is working. The output of the command should be something similar to the below output.

Docker check:

docker --version

Output:

Docker version 20.10.17, build 100c701

After installing the Docker, you can set up the docker-compose by referring to the given link. It is needed to build up the environment on the go.

Make sure the docker-compose is working by verifying the version information.

Docker Compose check:

docker compose version

Output:

Docker Compose version v2.12.2

Hopefully, “git” is installed on most of them. If you think you don’t have one, just go ahead and install it from your package manager or the link given below.

Git - Download

Lab-Setup - “Kurukshetra” Application 💻

Let’s clone the application from the GitHub repository and copy it onto your system.

git clone https://github.com/D4rk36/Kurukshetra.git

Navigate to the downloaded directory.

cd ./Kurukshetra

Inside the directory, you will find a “docker-compose.yml” file, which contains the instructions for running the application. You have to run “docker compose up” to bring up the environment.

docker compose up

Once the environment is up, let’s verify by accessing the app environment by clicking on the following URL: http://localhost:8066/ or paste it into your browser.

💡In case you are facing any errors. Please re-verify all the steps from the docker installation.

The page will be displayed below.

Bringing up the Docker instance might take a couple of minutes, based on your network speeds. You should also be able to see the log as displayed below while starting up.

During any time in the lab, you can run “Ctrl - c” to stop the running environment.

Additionally, to completely remove the “Kurukshetra” containers running from your system, run the remove command from the same directory where the docker-compose.yml file is present.

docker compose rm

Now that our lab environment is up and working, you are good to proceed to the next step of identifying the XSS vulnerabilities.

Summary

The setup is straightforward for users who are familiar with Docker. For other users who are new to docker, you might need to get adapted to using it. Most of the tools are now being containerized to avoid the installation process. Just download and run with docker.

Ensure your lab environment is working to jump-start learning about cross-site scripting vulnerability. The next articles will cover types of cross-site scripting vulnerabilities and techniques used to identify them. 😃

Additional References for XSS Practice:

• XSSy Labs

The following post is part of learning application security with the DVWA application.

Before jumpstart, ensure the docker DVWA application is enabled, configured, and accessible.

What is a Brute Force Attack?

A brute force attack is a trial-and-error method in which every possible combination of commonly used words, usernames, and passwords is tried out, hoping any of them will work.

Brute Force attacks are aimed at guessing commonly known files on the web server, breaking into email accounts, guessing remote services SQL or SSH server credentials (online), cracking password hashes (offline), etc., to gain unauthorized access to sensitive data or compromise security.

It would require a good amount of computing resources and time. #️⃣

The screenshot below from Cloudflare demonstrates how long it can take to crack a password based on the number of characters.

Today’s hardware helps us crack a hashed password of 5 characters or fewer in seconds. The one with 12 characters or more, combining small letters, upper-case letters, special characters, and numerics, takes years to crack. The bigger the password, the more time it takes to crack using a Brute Force attack.

Think wisely, how much time you would like to spend for any brute force attack. A day or two may be good, but years and decades may not be worth enough.

Speaking on behalf of security assessments, we will be spending days or weeks. But attackers do have all the time they want.

How do Brute Force attacks work?

Brute Force attacks are performed using automated tools or software. A massive list of dictionaries containing common passwords, usernames, words, etc., is generated and given to the tool as input.

The tool keeps interacting with the service and tries out the dictionary entries one by one until a valid match is found, at which point it stops.

During this process, the attacker uses large dictionary data sets until the correct combination is discovered and successful access to confidential resources is obtained.

From now on, we will use the “Burp Suite” as an ideal tool for all our brute force attacks and to keep demos focused. If you would like to learn more about the basics and usage of the tool, Check out the following post on BurpSuite Overview.

Next, I will be using a small custom dictionary of usernames and passwords for fast brute-force results, which will be performed later.

admin
administrator
user
john
dvwa
bob
alice
root
superuser
super

admin
admin123
password
password123
user
user123
administrator
passw0rd
r3m3mb3rM3
admin123$

Brute Force Attack - Demo

The DVWA application has a Login page functionality that can be used to brute-force and find the right match of user credentials, simulating the attackers to compromise the application.

Let’s go ahead and simulate the steps of an attacker and see if we can break in.

In information security, it’s all about chaining up every piece of information you know, experimenting with it, and confirming if it works. In short, it lies in your creativity when using the information.

At the moment, we do not have any information about the username/password. All we see is a login page.

We will start with the Brute Force attack using the above dictionaries.

Let’s start the BurpSuite tool and use the small custom dictionaries we created above. The tool tests for all possible combinations, and this method is scalable to thousands of combinations.

In the Burp Suite tool, navigate to the “Proxy” tab and click on the “Open Browser” button. A Chromium browser will be launched and will be displayed as shown below.

Log into the DVWA application using “admin/password” and navigate to the “Brute Force” item in the menu.

Let’s try some known username and password combinations.

Say “administrator/admin123”, “admin/admin123”, “user/user123” etc. For all incorrect attempts, we keep getting the “Username and/or password incorrect.” message.

Manually trying out is also known as a simple brute force attack, which is painful and limits the knowledge to oneself. This approach is time-consuming and isn’t scalable.

If you found a valid login match this approach? Excellent. You perfectly guessed it. 👍

In Burp Suite, we need to capture the Login request. I will enable the Intercept option to capture a specific login request so we can perform automated operations using it.

To enable it, navigate to Burp Suite “Proxy” tab ⇾ “Intercept” ⇾ toggle on the “intercept off” button. It immediately turns to “intercept on” as displayed below.

Key in some random data in the username and password file, then click on the “Login” button as shown below.

Once the Burp Suite receives an intercept request, you should be able to see the highlights immediately. Navigate to the “Proxy” tab. ⇾ “Intercept”. You should be able to see a request similar to the one below.

An HTTP GET method is used, remember the GET method doesn’t have a message body. Therefore, all the parameters and values will be sent as a URL.

GET /vulnerabilities/brute/?username=admin&password=testpassword&Login=Login HTTP/1.1

Here, we are trying to access a page called “/vulnerabilities/brute” and passing parameter values “username=admin&password=testpassword&Login=Login” to perform the login action required by the application.

If your credentials are valid, you will be able to log in successfully. Otherwise, you will receive an invalid login error message.

Now, click on the “Action” button and select “Send to Intruder”.

Switch to the “Intruder” tab, and you should be able to see the same request there. Under the “Positions” sub-tab, The tool automatically detects where all the changeable values need to be placed and highlights the five parameter values section for us.

I will clear all the payload locations and select only username and password using the “Clear” and “Add” buttons beside.

Types of Brute Force Attacks

There are four brute-force attack types that are supported by the “Burp Suite” tool.

Cluster Bomb best suits our requirements. Set the attack type to “Cluster Bomb” and switch to the “Payload” sub-tab.

In the “Payloads” sub-tab, select “Payload Set 1”, payload type as “simple list” and paste all the contents in payload options copied from the usernames.txt list.

This is for the “Username” values.

Second, select the “Payloads” sub-tab, set “Payload Set 2”, set the payload type as “simple list” and paste all the contents in payload options copied from the passwords.txt list.

This is for the “Password” values.

Observe that the request count is now set to 100. Using the two lists now, we will be trying out 100 possible combinations.

Lastly, click the “brute-force” button at the top right to initiate our brute-force attack.

In the BurpSuite Community edition it prompts with a warning box as some features are limited. Click “Ok” to continue.

An intruder window pops up, and the payload information and request status will be displayed below.

If you take a look, we can see we are getting a 200 status for each request, which means “200 Ok”.

How do we know which payload combination worked and which hasn’t?

One way is to click on each request with a 200 Ok status, select the “Response” sub-tab, and search for the string named “Username and/or password incorrect”. We know this belongs to a failed login attempt.

If the string isn’t present, it means the credentials combination worked, and that would be our match.

BurpSuite Intruder figured out there is one positive match on the bottom right side of the screenshot. This is a time-consuming approach.

Focus on the size of the length as shown below. For all incorrect attempts, the response message length is the same “4666”. Check one of a different length, i.e., 4704.

Observe whether the username/password combination “admin/password” worked. Navigate to the response sub-tab, We can see the “welcome to the password protected area of admin” message.

Hurray!! we found the right password match! 👏

Password Match Verification

It is always good practice to re-verify the security bug before we report it.

Make sure all the Intercepts in the proxy tab are toggled to off. Then, let’s return to the brute force page and verify our match to confirm our results.

Yep, our newly found password combination worked.

Excellent! We found a security bug using a Brute-Force attack, i.e., a guessable username and password.

You were able to learn a quick way to Perform a Brute-Force attack using DVWA.

I have used a short custom-built word list for demo purposes, Give a try with other lists. Search for “Brute-Force attack” or “Brute force wordlist”, and you will find many resources.

Here are some lists from Github.

Impact of Brute Force Attacks

The impact of a successful brute force attack can be severe.

• Unauthorized access to sensitive information.
• Financial loss
• Loss of organization’s reputation
• Leading to potential legal and financial repercussions for the affected individuals or organizations.
• Loss of customer trust, etc.

Preventing Brute Force Attacks

Security Researchers and web application developers need to be familiar with mitigation techniques. These skills can help them defend web applications from malicious actors.

So, let’s talk about some ways to detect it and then mitigate it.

Patterns of Brute Force Attack

Some of the common patterns can help to detect brute-force attacks on our webserver.

• Too many requests originate from a single IP address within a minute or hour.
• Multiple logins of a single user account from a different IP address and province.
• Excessive usage of the server resources and bandwidth.
• Increased number of failed login attempts of various usernames and passwords.
• Logged into multiple user accounts from a single IP address. (i.e., guessable default password) etc.

The above is a small list targeting user credentials, but the patterns vary for other resources.

Defending Brute Force Attacks

Brute force attacks are difficult to stop, but with good measures, we can limit the attack surface.

Avoid Using Default/Guessable Passwords

One of the most commonly exploited techniques says some application servers come with pre-defined default passwords for the initially created accounts. (Say “admin/password”)

Default Password Database - cirt.net

Some companies follow an initial password with the company name followed by a number sequence. Say “ABCCompany123” or the special character “ABCCompany123$”, some with established year appending at the end with a prefix of the usernames “Username2022” etc.

These are all unknown until someone figures them out. Once figured out, they are easy to try out with all the user accounts to which the user account has access.

Additionally, prevent users from using passwords such as “password”, “admin123”, “12345” etc.

Limit Login Attempts

One good practice is to limit the number of failed login attempts the user is allowed to make. Beyond 7 failed login attempts, the account is locked for a temporary time period. Like banks, beyond three failed attempts, the user account will be locked out for 24 hours. Or

👥The challenge with this type is that unauthorized users keep trying with valid user accounts and lock out genuine users.

Enforce a Strong Password Policy

A best-designed password policy like the use of a combination of small case letters, upper case letter, numerics, special characters will make it hard to crack for attackers.

• Use of password managers wherever applicable.
• Avoid re-using the same password.
• The length of passwords is to be 8 or above.
• Prevent the use of common dictionary words or guessable sequences.
• Use of certificates for authentication rather than passwords.
• Educate users about using a different password for all accounts.

Progressive Delay

This is also the best technique where the wait time keeps on multiplying with each failed login attempt.

Say, initially start with “60 Seconds” wait time at the first attempt, then 15 minutes of wait time for the second attempt, 60 minutes for the third attempt, and so on it goes.

Generally, some applications multiply wait seconds by 60 for each failed attempt.

Using Captcha

Captchas are used to filter automated bots or programs and prevent them from abusing the services.

🤖This is a bit of an inconvenience, but solving a captcha will help verify that it’s human and not automation.

Multi-Factor Authentication

Adding additional layers of verification makes brute force attack very tough. Using the OTP - One-time passcode, verification of token through email, or Security Questions before logging in makes it more difficult for attackers.

The attacker needs to compromise multiple sources to gain access to your user accounts which is very tough but not impenetrable.

Storing Salted Password Hashes

Even though our application is secured in all possible ways, some third-party plugins or disgruntled employees may lead to compromise of the application and say the attacker was able to gain access to all the passwords in the database.

When a user enters the password say “admin123” it is not a good practice to store it as plain text. It must be hashed and stored.

hash(admin123) = GX8N365FMeK9hsRkW9Dl2S/ikcQ

Now add salt to the above hash. Where salt does not need to be a secret text but a random text. ( say “5MU63YzoOm7ig”)

The Hash + Salt will be displayed as shown below

hash(admin123 + 5MU63YzoOm7ig ) = LL/0NIJmT2JcfCXkfOln62pj8Hw

The salted hashes make it much more difficult for attackers to crack the passwords offline.

Even though the attackers have salted hashes, it would be tough for them to crack and re-use them. Meanwhile, requesting the user to reset the passwords in case of compromise makes it more secure.

Whitelisting

Whitelisting or Allowing a list is an approach of letting only what you trust and blocking all the rest from accessing.

Let’s say for high privileged admin user accounts, employ a way to whitelist the login’s from known IP addresses or authorized VPNs and restrict all others from accessing admin features.

This reduces a huge attack surface.

Using Web application firewalls

Configuring and using Web Application Firewalls (WAFs) protects web applications from a wide range of attacks, such as brute force attacks, denial of service attacks, and malicious input filtering, etc. Examples: AWS WAF, Cloudflare WAF, etc.

More information on blocking brute force attacks can be found on the Blocking Brute Force Attacks OWASP site.

Conclusion

Understanding the basics of brute-force attacks and their potential impacts is crucial for safeguarding against cyber threats. By implementing robust security measures, such as strong password policies, multifactor authentication, and network monitoring, individuals and organizations can mitigate the risk of falling victim to a brute-force attack.

Using of captcha’s can be inconvinient feature, but use it cautiously to prevent automated bots or from automated attacks. Hope by this you are familiar with what a brute force attack is and how it can be exploited.

Keep Learning!! 😄

A single technique cannot mitigate XSS vulnerability completely. Using the right defenses can help in preventing XSS attacks.

One of the best practices is “Defense-In-Depth”, Enabling multiple layers of defense so even if a layer fails, other layers of protection can minimize the impact of an XSS attack.

Use Frameworks

In modern development practices, developers like to code faster and avoid recreating the wheel.

Rather than building applications from scratch, using the frameworks can protect the application from lots of vulnerabilities. As security features are in-built into frameworks and just need to enable.

For example input validation checks, XSS prevention, preventing access control issues, etc. (Some PHP frameworks include laravel, CodeIgniter,etc.)

Additionally, these frameworks do address the security vulnerabilities when discovered, all you need to ensure is that you are using the latest version of the application framework.

Validate Client Data

One of the most crucial steps is to validate each and every input received from the client.

As we have demonstrated throughout our articles, any data coming from the client side can be modified with the help of intercepting proxies.

For the same reason, each and every piece of data coming from the client must be validated then must follow through next steps of verification.

Output Encoding

Output encoding is one of the techniques used to take user-controlled data and safely display it without interpreting it as code, and considering it as text.

Below is an example XSS payload.

<script>alert(document.domain);</script>

HTML-encoded text of XSS payload will be displayed as shown below.

<script>alert(document.domain);</script>

• “<” changed to “<”
• “>” changed to “>”

As the browser parses HTML, JavaScript, CSS, and URL differently. Each much be encoded depending on the requirements.

Another good example in PHP, the “htmlspecialchars” function will convert the “<” less than, “>” greater than symbols to HTML entities such as “<” for less than, “>” for greater than respectively. This again makes the application treat all as text without breaking the syntax.

URL, HTML, JavaScript, and CSS can be encoded.

Sanitization

In some cases, the users need to retain HTML code as it is. In this case, the output encoding will break the document structure.

To retain the data as it is, the sanitization technique is used.

As part of the sanitization, it produced a new HTML document that contains only the “safe” or allowed HTML tags. This prevents XSS, this is performed in combination with the whitelist and blacklist approach.

Example, In PHP we used a “strip_tags” function is used to filter out all the HTML tags, the “addslashes” function escapes the special chars like a quote, and a double quote with backward slashes to retain it as text without breaking code syntax.

XSS Header

The X-XSS-Protection response header is one of the features used to prevent the reflected XSS from executing.

Below is an example of enabling the XSS protection header by completely blocking script execution.

X-XSS-Protection: 1; mode=block

The following can be ignored if the strongly protected “Content-Security-Policy” is being used.

HTTPOnly - Cookie Attribute

This is another cookie flag that helps in reducing the XSS impact. Enabling the “HTTPOnly” flag for session cookies can prevent the javascript code from accessing it.

Content-Type

Content-Type is one of the response headers which specifies the type of content delivered. It is recommended to set the script content to “application/json” than “text/html”

Content-Type: application/json

Setting the content type to “application/json” prevents the execution of script tags.

Content Security Policy (CSP)

Content Security Policy is an added layer of security protection. This helps in detecting and mitigating the XSS and other code injection attacks.

CSP instructs the browser on how to deal with the content. On CSP-enabled websites, it becomes very hard to exploit the XSS vulnerability.

A Content-Security-Policy header is appended by the server with policy configuration.

Content-Security-Policy: default-src 'self'; img-src *; script-src userscripts.example.com

Above is an example of CSP, instructing the browser to permit only content from the same site, images from anywhere, and execute scripts only from “userscripts.example.com”

Whitelisting rather Blacklisting

Whitelisting or allowing a known good is an approach of letting only what you trust and rejecting all the rest.

Whitelist is one of the supporting steps adding to all the above defense layers. Even in the case of unknown payloads as well whitelist defends well.

Let’s say allowing the trusted characters upper case, small case letters, numerics, and some special characters based on need.

Limit usage of the blacklist only for reasonable business requirements.

Use Web Application Firewalls (WAFs)

Configuring and using Web Application Firewalls, protects web applications from a wide range of attacks like XSS, Brute Force attacks, Denial of Service attacks, Malicious input filtering, etc. a lot more.

Say AWS WAF, Cloudflare WAF, etc.

Additional References:

More information on mitigating XSS attacks can be found on the OWASP site.

• Cross Site Scripting Prevention - OWASP Cheat Sheet
• DOM based XSS Prevention - OWASP Cheat Sheet

Firstly, we will go through the standard practices that are generally used for mitigating the command injection vulnerabilities, followed by we will be covering how the vulnerability has been fixed in the DVWA application.

Avoid Calling OS Command Directly

One of the most effective ways is to avoid calling all the system commands directly by taking from the user input.

Using the built-in library functions is a good option, as it performs the tasks intended without tampering.

In our command injection examples, the application takes the domain name, and IP address then followed by we could append the additional system commands. The application doesn’t filter and is directly passed on to the server for execution.

If you were able to view the source code, the “shell_exec()” function in PHP is being used for taking all our user inputs and passing them to the server.

shell_exec( 'ping -c 4' . USER_INPUT );

The escapeshellcmd() or escapeshellarg() can be used instead of “shell_exec()” to prevent command injection. What it does is, it passes everything within a single quote ensuring to run all of one text rather than breaking it into multiple commands.

If you think, in your current scenario you can not avoid it but that’s the only way to go ahead. then there are other ways to mitigate it.

Whitelisting

As we covered whitelisting earlier. Whitelisting is an approach of letting only what you trust and rejecting all the unknown.

• Allowing only the valid characters, like small case letters, upper case letters, and numerics.
• Limiting only the special characters which are supposed to be used. (say, allow period “.” and reject all)
• Only allowing the system command that the user is supposed to use.

In the command injection “high” example, we say the blacklisting is being used to filter a lot of characters, where the ‘|’ OR and SPACE operator are being filtered than of “|” only OR operator.

Blacklisting can be used but is more of an error-prone approach.

Strong Input Validation

Validating the inputs in conjunction with whitelisting provides a strong defense.

Treating every input from the client can be tampered with, verifying the inputs and ensuring it is clean from all types of malicious payloads.

A parameterization is an option where the command and the input data can be segregated using a structured mechanism. This helps in quoting the input data before processing.

Never escape the user input with metacharacters directly as it is more error-prone.

Additionally, the Regular Expressions can also be used for filtering the input before processing.

Least Privilege User Account

Use a user account with minimal privileges to execute the needed system operations on the server rather than one having admin privileges.

Command Injection - Fix (DVWA)

Let’s see how the vulnerability was fixed in the DVWA application.

Log into the DVWA application and set the security level to “Impossible”.

Navigate to the “Command Injection” and click on the “View Source” button at the bottom.

Note, only the partial code is displayed below.

// Split the IP into 4 octects
$octet = explode( ".", $target );

// Check IF each octet is an integer

if( ( is_numeric( $octet[0] ) ) && ( is_numeric( $octet[1] ) ) && ( is_numeric( $octet[2] ) ) && ( is_numeric( $octet[3] ) ) && ( sizeof( $octet ) == 4 ) ) {

    // If all 4 octets are int's put the IP back together.

    $target = $octet[0] . '.' . $octet[1] . '.' . $octet[2] . '.' . $octet[3];
  // Determine OS and execute the ping command.

Code Snippet 1: Command Injection - Mitigation

In the above screenshot, the developer now has removed all types of blacklisting approaches and moved to a whitelist.

At the moment, only numeric IP addresses and a special character of a dot are allowed and reject all the other input.

This reduces the attack surface to a greater extent for exploitation.

More information about the mitigation techniques can be found on the OS Command Injection Defense - OWASP Cheat Sheet.

I Hope, Now you can secure your web applications from the command injection vulnerabilities. Thank you! :)

Required Tool Set

1. A working DVWA docker image will be needed.
2. BurpSuite Community Edition tool.
3. Wordlists (username.txt and password.txt)

If you are unable to follow any of the sections, refer back to the earlier posts.

DVWA - Brute Force Attack and Prevention Explained This detailed guide explains Brute Force Attacks, how they work, and ways to prevent them.

DVWA Brute Force Attack - Medium This detailed post explains Brute-Force Attacks’ Medium severity using DVWA and how partial security fixes can be bypassed.

DVWA Brute Force Vulnerability - Demo

Log into your DVWA environment, and click on the “Security level” menu on the left sidebar.

Select “High” and click on the submit button, as shown below, to ensure the Security Level is updated.

Re-testing Scenario

Imagine the development team returning again and informing you that the vulnerability is fixed and needs re-verification.

Let’s go ahead and repeat all the steps.

1. Launch the BurpSuite Community Tool.
2. Navigate to the “Proxy” tab -> “Intercept” sub-tab and click on the “Open Browser”
3. Once the Chromium browser is launched, login to the DVWA application using admin credentials.
4. Visit the “Brute Force” link in the menu.
5. Switch to the Burp Suite “Proxy” tab, select the “Intercept” sub-tab, and toggle “Intercept is Off” to enable it.
6. Enter the random values in the username and password fields, then click on “Login”.
7. The “Intercept” captured login request will be displayed below.

In line number 1, the test values are placed in the username and password fields. In line 16, the security level parameter is set to high.

Additionally, a new “user_token” is being passed in the URL parameter compared to the previous requests.

A copy of the previous request is provided below.

1. Click on the “Action” button or right-click and select “Send to the Intruder”.

2. In payload positions, “Clear” all the selected payload placeholders and then select the “Username” value field and the “Password” value field by clicking the “Add” button for placing custom payloads.

Choose the attack type to “Cluster bomb”

The same word list of common usernames and passwords can be used for the current scenario. Save the text files onto your system or use copy-paste to load the information in the payloads tab.

usernames.txt

admin
administrator
user
john
dvwa
bob
alice
root
superuser
super

passwords.txt

admin
admin123
password
password123
user
user123
administrator
passw0rd
r3m3mb3rM3
admin123$

In the “Payloads” sub-tab, select “Payload Set 1”, set the payload type as “simple list”, and paste all the contents in payload options copied from the usernames.txt list.

Second, select the “Payloads” sub-tab, set “Payload Set 2”, set the payload type as “simple list” and paste all the contents in payload options copied from the passwords.txt list.

Switch to the “Options” sub-tab and enable the “Grep - Match” with the “incorrect” string. so we can understand which requests have failed.

Lastly, click on “Start Attack” and monitor the results.

Failed Intruder Attack Results

Only in one response was the “username and/or password incorrect” string found.

For all other requests, we are getting “302” status codes instead of “200 OK”, which means something is not working and our brute force attack is failing.

Now, shall we assume that the “Vulnerability is fixed” and close the security flaw?

Well, we can close it. But this is a strange scenario in which we don’t see errors or warnings.

Let’s analyze more thoroughly and see what exactly is happening here. and why we are getting “302 Found” redirects.

Remember, you can automate only if application behaviour is consistent.

Re-submit the username and password with new random values on the Brute Force login page and intercept the login request.

Analyzing with the BurpSuite Tool without going to the browser gives us more control over the HTTP messages. Therefore, I want to view the HTTP response messages in the Burp Suite itself.

Let’s enable the option to Intercept and view the “Response” messages received from the server before sending them to the Browser.

Visit the “Proxy” tab -> Select “Options” sub-tab, scroll down to “Intercept Server Responses” and enable “Intercept responses based on the following rules” as displayed below.

Switch to the “Intercept” sub-tab under the “Proxy” tab and click on the “Forward” button.

The “Forward” button will send the request to the server and now start “Intercept” immediate HTTP “Response” received from the server and display it as shown below.

By clicking on the “Forward” button again, the response is now sent to the browser.

Toggle the proxy “Intercept is on” to disable it.

Use the BurpSuite “Chromium browser” session, manually try for random username/passwords say “administrator/admin123”, “admin/admin123”, “user/user123” etc.. with 4 or 5 incorrect credentials.

For all incorrect attempts, we keep getting the “Username and/or password incorrect.” message.

This confirms that the “Brute Force” attack still does exist, which means the Vulnerability remains Open. Yay!!. :)

Now the question is, why is our Intruder tool unable to pick it up?

Let’s review all the previous HTTP messages and see if we can find any patterns.

The Burp Suite HTTP message history can be found under the “Proxy” tab -> “HTTP history” sub-tab.

Observing the HTTP GET requests that we have manually tried, the username and password values are being passed, but one parameter value keeps on changing in the “URL” section.

Remember a new parameter is being passed on the Login request? Yes, “user_token”.

The “user_token” keeps updating for each request. Therefore, we cannot use the same “user_token” for all HTTP requests.

This is the reason our tool fails. If we perform brute force manually, it works!

Finding the origin of “user_token”

Let’s find out from where the “user_token” is being set and updated.

In the case of HTTP, it can be set in Headers, Response Bodies, or Cookies. Let’s review the HTTP responses received one by one.

After a thorough review Of one of the requests from HTTP history, I was able to find out it is being set in “HTTP Response Body”

<input type='hidden' name='user_token' value='90f9f7a06213b032dbe9e5d1d4717ce0' />

The code is a simple HTML tag that is hidden in the background of the “Login” page and passed every time when the user submits “username” and “password” credentials.

Based on the above request, the HTML input tag is dynamically generated on the fly with an updated “user_token”.

We found the source! Can you automate it with Burp Intruder? Yes

One more important point to discuss before we proceed.

Choosing the Intruder Attack Type

Guess what the attack type could be here?

Cluster Bomb? NO

Remember what the “Cluster bomb” does? It tries out all possible permutations and combinations by varying the first “Payload 1” and keeping the “Payload 2” standard, then jumps to the next permutation.

A big challenge here is, you cannot keep the “user_token” same for multiple requests.

Therefore, the “cluster bomb” doesn’t meet our requirements.

What about “Pitchfork”?

Yes, the “Pitchfork” option helps in the current scenario. Takes the first payload from “Payload set 1” and the first payload from “Payload set 2” and then iterates through.

Overall, our current wordlist of usernames and passwords generates only 10 possible payload requests, as shown below.

We could definitely miss our valid combination match. i.e., “admin/password”.

So, to brute force from here on, we need to use the username, which definitely exists on the server. (say “admin”)

The DVWA dev team gave us a good challenge. Let’s put in additional efforts to perform the Brute Force attack.

Fine-tuning the Intruder Payload

Repeat all the steps from step 1 to step 7 mentioned above, from the launching of the BurpSuite to sending the new log-in request to the intruder.

Use a completely new intercepted Login request, else intruder is bound to fail.

Choose the “Pitchfork” attack type and select two payload positions. i.e. password value field and user_token value field as displayed above.

This time for payloads, the first position will be of the password value field and the second position will be of the user_token value field.

Select the “Payloads” sub-tab, set “Payload Set 1”, payload type as “simple list” and paste the passwords.txt list contents into payload options.

Second, select the “Payloads” sub-tab, set “Payload Set 2”, and payload type as “recursive grep” from the list. This is for the “user_token” field.

The “recursive grep” is used when you want to extract specific data from the previous response and use it in the request as a payload.

The “Grep - Extract” feature is used to find specific strings based on the pattern or use regular expressions to get useful information from the HTTP response.

Next, go to the “Intruder” tab -> “Options” sub-tab, scroll down to “Grep Extract” and click on the “Add” button.

A new window named “Define extract grep item” is loaded.

In the “Define extract grep item” window, click on the “Fetch Response” button on the right side.

The “Fetch response” will take the currently configured request in the “fetch” tab and fetch, the server response for it.

Once the HTTP response is loaded, Using the mouse select the user_token value then select only the value string highlighted as shown below.

The “Start after expression” and “End at delimiter” values will be auto-populated. Just click on the “OK” button to proceed.

Use “Ctrl - c” to copy the token value “1802dab0e42ee4ef48e71d491981abb1” will be used for updating initial payload.

Switch back to the Intruder Payloads section. Observe the “Grep Extract” pattern updated and displayed in “Payload Options”.

Now, set the “initial payload for first request” value as the one we copied earlier, the latest token “1802dab0e42ee4ef48e71d491981abb1”.

All set, but there is one more thing to do.

Remember, a new user_user token can be fetched only when you send each request one by one after updating. If thrown multiple concurrent requests at once than we can’t get correct user token in sequence.

In the “Intruder” tab “Resource Pool” is a place where we can fine-tune the number of threads to use or delay between requests etc.

Navigate to the “Intruder” tab and select the “Resource Pool” sub-tab. Select “Create new resource pool” named “Brute Force Attack - High”.

Set the “Maximum concurrent requests” to 1.

Done, we have configured our intruder and now click to “Start attack” button.

Wow!! finally accomplished. 😄

The intruder configuration works, and we no longer see the “302 Found” redirect status codes being displayed.

Observe the user_token value taken from the previous response field, displayed under the “value” row and updated in the request as the “Payload 2”. The fine-tuning worked!

Let’s check the one with of different length “4792” and Yes, We found our credentials match (admin/password).

The “Grep - Match” flags can also be enabled.

Well done!! 🎉

Thus, the Brute force vulnerability still remains open.

We have covered a lot of ground here to exploit the Brute Force attack. Re-visit the article and keep practicing until you become familiar with it.

Check out the below article to learn more about prevention techniques.

DVWA - Brute Force Attack and Prevention Explained

In the current section, we will explore a bit more about the Brute Force attack and options available in the BurpSuite tool for effectively identifying successful brute-force attempts.

If you haven’t read the previous article about the Brute Force attack, feel free to refer to the bookmark below.

DVWA - Brute Force Attack and Prevention Explained

DVWA Brute Force Vulnerability - Demo

Imagine we found a vulnerability and reported it to the DVWA development team. The team reverted, claiming the security flaw was fixed.

Trust but Verify

It is always a good practice to re-verify and ensure that the vulnerability is mitigated as per best practices. Let’s verify.

Log into the DVWA application. In the sidebar, scroll to the bottom of the page and click on “DVWA Security”. A page will load as shown below.

Set the security level to “Medium” and click on the Submit button. Ensure it is updated and displayed on the left side at the bottom of the page.

Launch the BurpSuite tool, navigate to the “Proxy” tab, and click on the “Open Browser” button.

Visit the DVWA application, Select the “Brute Force” vulnerability, and then enter any random credentials as discussed in the previous article.

Enable the intercept option and capture the login request displayed, as shown below. Observe that the security parameter value is set to medium in line 16.

Similar to the previous lesson, click on “Action” and select “Send to Intruder”. Set the attack type to “Cluster bomb”, clear all fields, and add only the username and password value fields for inserting custom payloads.

For the current scenario, we will use the same Word list of common usernames and passwords. Save the text files onto your system or use copy-paste to load the information in the payloads tab.

usernames.txt

admin
administrator
user
john
dvwa
bob
alice
root
superuser
super

passwords.txt

admin
admin123
password
password123
user
user123
administrator
passw0rd
r3m3mb3rM3
admin123$

In the “Payloads” sub-tab, select “Payload Set 1”, payload type as “simple list”, and paste all the contents in payload options copied from the usernames.txt list. (For username values)

Second, select the “Payloads” sub-tab, set “Payload Set 2”, and payload type as “simple list”, and paste all the contents in payload options copied from the passwords.txt list. (For password field values)

The steps were similar to the previous one.

If you remember, in the previous Intruder attack summary, we needed to go through each request, select the response message, and look out for the message “Username and/or password incorrect”.

We earlier used the “Length” size option to drill down and focus on the one with a different size.

The Intruder tool provides us with a better way to do it, called “Grep - Match”, which helps us to find a specific string in the HTTP response body using grep and flags it. A more suitable way to view the results.

In the “Intruder” tab, click on the “Options” sub-tab and scroll down to “Grep - Match”, then click on the “Clear” button.

If prompts for confirmation, click on “Yes” to clear.

In “Grep-Match”, type “incorrect” in a text area and click on the “Add” button. This word is taken from the invalid user credentials error message “Username and/or password incorrect”.

Make sure “Flag result items with responses matching these expressions.” is enabled and confirm “incorrect” string is added.

Match type “Simple string” suffixed our current requirement.

Finally, click on the “Start attack” button and let us verify whether the brute-force vulnerability is fixed or not.

A new window pops up, and all the Intruder attack summaries will be displayed. Now, an additional row named “incorrect” is added.

You can see that our grep match pattern is working, as we are able to view the match count in the “incorrect” row updated for each request.

If you closely observe, there is one problem. It is slow compared to the previous brute-force attack.

It seems the DVWA development team added a small delay, but it’s still not stopping us from performing a Brute Force attack.

It took more time than before, but we found a valid password match again using the brute-force attack.

The one where the “incorrect” count is empty. i.e., admin/password. As displayed in the above screenshot.

Scroll down to check for the response body and observe a message. “Welcome to the password protected area of admin”.

Yay!! The vulnerability still remains open. Let’s report it back to the DVWA dev team. 😄

DVWA Informational (Optional)

We are testing this in a DVWA, an intentionally vulnerable environment. The application also allows us to view the backend code for knowledge purposes.

Remember you might not have this option in real-world applications.

Navigate to the “Brute Force” menu item in the sidebar. On the same page click on the “View Source” button at the bottom of the page.

A pop-up window will be loaded, and the code will be displayed.

Observe that the application delays 2 seconds before sending the response message back to the client for all failed logins.

In general, the vulnerability can be mitigated in many ways, but industry best practices should be adhered to.

What is DVWA?

Damn Vulnerable web app or Damn Vulnerable Web Application (DVWA) is an intentionally designed vulnerable application for pen-testers and security experts in learning and testing web application security in a legal environment. It is developed using PHP/MySQL and can be deployed easily using an Apache server.

DVWA Git Repository

DVWA can be installed in multiple ways, such as using code from GitHub, Vagrant, or a Docker image, etc.

It is recommended to host the vulnerable applications in a host-only environment to prevent compromising other systems on your network by attackers.

You can even view the source code or contribute to the DVWA project. It’s an open-source project.

For simplicity, we will be using our systems and pre-built docker DVWA image, which is publicly available, rather than setting up the whole stuff by ourselves. By running the DVWA docker container, we can save a lot of time and jump-start learning application security and penetration testing directly.

Requirements

1. Docker installed & enabled on your Laptop/Desktop
2. Any Operating System (OS) Linux/Windows/Mac

I am a GNU/Linux user, so most of the commands you will see from here on will be based on Linux (Debian), and similar commands do apply to other Linux flavors like Ubuntu and Mac with minor tweaks.

For Windows users, you can use either PowerShell or git Bash, where similar commands can be executed, or even the Windows Subsystem for Linux can also be used.

Verify Docker Setup

docker --version

Output:

Docker version 20.10.17, build 100c701

If the output is similar to the above, it means the docker is installed on your system and good to start.

For users whose docker is not installed, please visit the Get Docker page for installation.

Manage Docker as Non-Root Users (Linux-based OS Users)

For users who are using docker on Linux-based operating systems, we need to take one more additional step to ensure we can manage the docker image as non-root users.

After installation of docker, create a docker group and add the newly created user to the docker group.

$ sudo groupadd docker

$ sudo usermod -aG docker $USER

Now log out of the user account and log back in again to verify you are now able to manage the docker instances from non-root users.

$ docker run hello-world

Output:

The above output confirms that we can manage Docker with non-root user privileges. More details can be found on the post-installation docker page below.

Benefits of Local DVWA Environment

• Practice any time.
• Ability to test any customized payloads or exploits.
• It can be used to test the effectiveness of Web Vulnerability Scanners or Automated Tools
• It can be used for Teaching.
• Ability to test custom security fixes.

Running DVWA docker

I hope your Docker environment is configured so we can start working. Here, we will use the Docker image, which has already been built and hosted in the Docker Hub.

Damn Vulnerable Web Application Docker Image: https://hub.docker.com/r/vulnerables/web-dvwa/

Command:

docker run --rm -it -p 80:80 vulnerables/web-dvwa

The above command will download the docker image for the first time and will start immediately on port 80 after downloading it. Click here to verify.

If you are using port “80” for some other service in your operating system, you can change the docker container port to some random one (say 8443). Update the -p value with -p 80:8443. Ensure the updated port is used in the URL while accessing the DVWA web application.

To manually view, open a browser and visit “http://localhost/”, you should be able to see the output as shown below:

The image will start displaying the console logs of the operations being performed on the DVWA website for reference.

Stop the running Docker image anytime by typing Ctrl - c in your console.

DVWA Admin Password

Now log into the application using Username admin, Password as password, Navigate to Setup DVWA ⇾ click on Create/Reset Database button.

We can observe that the database has been created with a users’ table. Some sample data is also inserted into the tables for our testing purposes.

Damn Vulnerable Web App Walkthrough:

Log into the DVWA application and observe most of OWASP’s top-known vulnerabilities that have been created so you can get started. They are displayed as shown below.

Our practice lab environment is up and is good to go.

From the above screenshot, you can use the DVWA to practice and get hands-on experience with known vulnerabilities, such as Brute Force, Command Injection, CSRF, XSS, etc.

Click on any vulnerability in the left-side menu, and the application will load the vulnerable page. All pages simulate close-to real-time application behaviors and provide hints to help you narrow down and use the correct type of vulnerable payloads for exploitation.

Remember that all our changes will be lost once you stop the DVWA docker image. You might need to repeat the above steps when you start. This is how the docker is designed, and it also allows us to begin with a fresh environment without worrying about previous changes.

The docker image needs some more tweaks, but we will do them when needed based on the type of attack we are discussing.

DVWA Security Levels

In the DVWA application, there are multiple levels to test any specific vulnerability, ranging from Low to Medium to High and Impossible.

These levels help you build skills by understanding each scenario. First, you learn about the attack itself. Then, you will know how broken fixes are implemented and how they can be bypassed. Lastly, you will learn the best way to secure a particular functionality.

The DVWA security levels are different for older versions. In the old version, high is a good practice for fixing code.

It is recommended that you go step by step. I still use it today to test specific payloads before they are applied to real-time applications as part of security testing.

DVWA View Source and View Help

The DVWA application is mainly designed as a learning platform for application security. It also allows us to view the backend code for knowledge purposes.

Remember, you might not have this option for real-world applications. This is just for educational purposes only.

Navigate to any vulnerability in the menu. Say the “Brute Force” menu item in the sidebar. On the same page, click on the “View Source” button at the bottom.

Similarly, the “View Help” button or “More Information” section can be used if you struck somewhere as initial help.

I hope the above information helps you to get started with a damn vulnerable web app docker.

If you want to learn about some basic web foundations before jumping into web security vulnerabilities, refer to the bookmarks below.

Security Foundations: What is Web Application and How does it work? Discover the fundamentals of what is a web application, URLs, and popular web application architectures. Gain insights into the core concepts that drive the digital world forward. Begin your journey by establishing strong security foundations.

Security Foundations: HTTP Basics Tutorial Uncover the fundamentals of HTTP in this beginner-friendly way. HTTP Basics Tutorials is a guide for those new to information security or diving into web application security.

FAQ’s

How to log into a damn vulnerable web app login?

You can use the credentials like username as admin and password as password.

We will cover the sections of BurpSuite individually as we keep trying for security vulnerabilities.

BurpSuite(owned by portswigger) offers three variants, a community edition, a professional, and an enterprise edition. We will use community edition throughout the articles, which suffixes our requirement.

Burp Suite can be found on the PortSwigger website: https://portswigger.net/.

Once you are familiar with security assessments and concepts, I would recommend you to go for the professional edition as it has many more benefits, like saving the sessions, optimizing scans, scheduling the assessments, etc.

BurpSuite professional edition saves a lot of time while performing real-world security assessments.

OWASP ZAP is an alternative. You can also use it or keep using the BurpSuite community edition, which has limitations but can help complete our work.

BurpSuite Installation

Visit the PortSwigger website and look for Burp Suite downloads.

1. Make sure you are downloading the community version.

2. I am using the Linux-based OS, therefore choosing the Linux (64-bit) version and clicking on the “Download” button.

3. Click on the “Show Checksums” after downloading. It is displayed as shown below.

1. use md5sum or sha256 sum from the command line to verify your download.

$md5sum burpsuite_community_linux_v2022_7_1.sh
c48c31aa69754adaf394a215dff0ecc5 burpsuite_community_linux_v2022_7_1.sh

This helps to verify that the file you have downloaded is indeed from the portswigger release and not tampered with by any malicious users.

1. The installation is straightforward. Make the script executable using the chmod command.

If you are using Kali Linux, the BurpSuite will come pre-installed.

chmod u+x burpsuite_community_linux_v2022_7_1.sh

1. Run the executable and follow the instructions.

./burpsuite_community_linux_v2022_7_1.sh

Select where you want to install the BurpSuite and click on the next.

Keep the default for the location of the symlink and click on next.

Click on “Finish” to complete the installation.

Starting BurpSuite

Navigate through your system application, look for the “BurpSuite Community” icon, and click to launch. It can also be found manually by going to the BurpSuite installation directory and running ./BurpSuiteCommunity.

Here we can observe that the saving of the project feature is only limited to the professional edition.

Select the Temporary project and click the “Next” button to continue.

Custom configuration in BurpSuite gives you more control over how the tool must behave, what type of checks you want to enable by default etc. This we will be covering more in the advanced section.

Let’s start using the BurpSuite defaults and click the “Start Burp“button.

Finally, the BurpSuite will be launched and will be displayed as shown below.

The installation process will be very similar to Mac and Windows operating systems, with minor changes.

Ensure your BurpSuite is installed and running before continuing to the next section, the BurpSuite overview.

What is a web Application?

Web applications are programs designed to perform specific operations for users or other applications.

Examples: Reading News, Watching Videos, Editing Photos online, etc.

As users, we will be using Web Browsers like Chrome, Firefox, etc., to interact with the web applications where numerous actions are performed by our browsers behind the scenes once we give domain information in the URL bar.

Have you ever wondered how different browsers handle all these functions, and you get similar results in all Web Browsers to the most extent?

The Internet Engineering Task Force is a standards organization body for the Internet and other technical standards.

The standards body is an individual or group of engineers and computer scientists who publish the methods, behaviors, innovations, and standards of how the internet and internet-connected systems should work.

Request For Comments (RFC)

RFC: After lots of peer review and evaluations are done for each proposal, it is standardized, and each proposal is given a Request For Comment (RFC) number. Therefore, all the applications developed to work with the internet must adhere to RFC standards.

I recommend going through RFC documents whenever you want to learn further. This might help you uncover new security bugs.

What is a URL?

URL is an acronym used for the Uniform Resource Locator. It’s a type of web address that specifies the location of a specific resource on the internet.

URL consists of different components. Let’s look at them in detail.

1. Protocol - A standard used for processing data.
2. Domain Name - A user-readable address pointing to an IP address on the internet.
3. Port - Specific port used for communication. (HTTP runs on port 80, and HTTPS runs on port 443).
4. Path - It represents the file or subdirectory structure on the server.
5. Parameter - A special kind of variable defined to pass values for processing.
6. Value - The value of a parameter assigned. It can contain characters and numerics.

How does URL work?

When you type a URL in your browser, the first request will be sent to the Domain Name System (DNS). In DNS, it will look out for the mapping IP address for the given domain name and send IP information to the browser.

Next, the browser uses the IP address information received and initiates the TCP connection with the Server. Once the server responds with confirmation, a valid channel is established and starts exchanging requests and responses.

Web Applications Architectures

Let’s dig a bit deeper. All web applications and technologies are logically connected for client-server communication to ensure a better web experience.

From here on, we will refer to all the operations performed on the user side as Client (Ex, Web Browsers, Terminal, etc.) and one which accepts our request and responds as Server (Example: Nginx, Apache, etc.).

As of today, web application architectures have become very complex. Let’s start with the basics without worrying much, and you can build on your expertise from here on.

Client - Server Architecture (2-Tiered)

In the case of client-server architecture, A web application is hosted on a single server that will process all the client’s requests and respond back.

Client - Server Architecture (3 - Tiered)

In the case of client-server architecture, A web application is hosted on multiple servers, a Web Server and a Database Server, where the web server takes a request from clients and fetches the necessary data from the database, formats it and sends it back to the client requested.

Client - Server (n-tier)

In the case of n-tier architecture, there can be any number of Web and Database servers, where all the traffic being received from the client is routed to the server with less load. Most of today’s applications are deployed similarly to the above architecture.

Technologies

Technologies are generally classified into two types.

1. Client Side Technologies
2. Server Side Technologies.

Let’s check out some examples. You might already be familiar with some technologies.

Client Side Technologies

Our browser understands HTML, CSS, and JavaScript technologies whenever the server sends information using them. The browser renders and displays the content in a human-readable format by hiding all complex code from the user’s view.

Server Side Technologies

In the screenshot above, we highlighted a few programming languages like Python, PHP, Golang, etc., but there are many more server-side technologies. These high-level programming languages run on the server, process data, and format the data into a format the client can understand.

Conclusion

I hope you have some idea about the web and its technologies by now.

Next, Refer the HTTP basics, which are helpful for security assessments and used by developers and administrators to understand what the server says and take action based on it.

Security is a significant concern for any website these days. To help provide security to their users, many websites have adopted the proposed security standard of a security.txt file to allow researchers and hackers alike to find vulnerabilities and report them without fear of legal reprisal. This article will discuss what security.txt files are, how they work, why your business/owner of the website should care about adopting them, and more!

What is a security.txt file?

It is one of the proposed website standards that allows owners and security researchers to work more closely to report any identified security issues.

This “security.txt” file is a new open standard and still in the draft stage, used by website administrators, bug bounty hunters, and other security researchers who want to share information about discovered vulnerabilities with website owners in an organized manner.

How does security.txt work?

If you are the site owner, you list contact information for reporting vulnerabilities (such as an email address and PGP key) in your security.txt file, and researchers can use this information to report any issues they find privately. By doing this, you make it easier for researchers to report vulnerabilities.

“security.txt” is generally placed on your website at https://www.example.com/.well-known/security.txt

Here are the example contents of the security.txt file.

Why should you care about security.txt?

A common phrase in the security industry is, “Security is only as strong as the weakest link.” A single security bug is more than enough to compromise the complete chain.

The website owner might ensure all the necessary steps to protect their online asset from all malicious actors.

The security vulnerabilities are like the “Cat and Mouse” story as the developers continuously work in a fast-paced agile environment to deliver value to the customers in a shorter time, where some security issues might go unnoticed.

However, if an attacker can find and exploit a vulnerability on the website that was not patched or adequately addressed, it can potentially do much damage.

As a site owner, you should care about adopting security.txt files because they can help make it easier for researchers to report vulnerabilities to you privately and securely. This can help protect the researcher and your website from legal repercussions if the vulnerability is not reported responsibly.

Additional Benefits:

• Information about the organization’s secure disclosure policy can be stated so that researchers can look at and comply to the best extent.

• The security.txt file helps information to communicate directly with the respective security team, who is already familiar with the reported topic.

• Security researchers can also understand what part of the website is in scope for testing and what is not part of the scope.

• Acknowledgments for all the previously reported security researchers.

• Links to job references if the organization seeks a security analyst or red team expert.

It is easy! You can create a security.txt file using this handy tool: https://securitytxt.org/#generate

References

• https://en.wikipedia.org/wiki/Security.txt
• https://securitytxt.org/ - Template Generation
• https://github.com/securitytxt/security-txt

This post will start with what an XSS vulnerability is and then will try to analyze the XSS challenges on the vulnerable app.

Ensure your lab is up and running if you have not set up your lab yet.

What is Cross-Site Scripting?

Cross-site scripting is also referred to as “XSS.”

Cross-site scripting is an application flaw that takes a malformed input from the client (i.e., Browser or Proxy) and the server without verifying appends, then sends the input as it is back in an HTTP response without proper validation.

If you are not familiar with what HTTP is, check out the following HTTP Basics Tutorial to help you get started.

The malformed input lets an attacker inject malicious code(like HTML or JavaScript ) into the server’s HTTP response and can change the application’s behavior.

XSS vulnerability can be used to deface the landing pages of websites, which is called defacement. Stealing user sessions and gaining access to user accounts. Secretly log and monitor the victim’s keystrokes, Control the victim’s web browser, retrieve user-saved passwords from the browser, Or even redirect victims to a malicious page, and much more.

Additionally, XSS, combined with other security vulnerabilities, makes the attack more severe.

In total, there are three types of XSS vulnerabilities, as detailed below.

Stored XSS - Walkthrough

After setting up the lab, Visit http://localhost:8066. The vulnerable Kurukshetra application should be loaded as shown below.

Take some time to understand how the application functionality works before we start assessing.

Try adding a simple “HelloWorld” string, and check how the input is appended to the below comments.

From the above behavior, we can understand that the given input is stored and displayed back.

💡 This is one of the signs where you can check if it can accept any malformed input as well. Let’s go ahead and try out the classic XSS payload.

*<script>* tag in HTML is used to extend the page capabilities and include interactivity, which will be used to test if it is possible to inject the code snippets.

alert() function in JavaScript is used to display the popup window.

I will insert the script code to make things visually appealing, as displayed in the image below. When we see the popup window, it means our script code got injected and executed successfully.

Inject the script code in the input field and click the “Submit” button.

Immediately, a popup message will be displayed, as shown below, to confirm our script execution.

Click the “OK” button, and the application usually loads the page.

To further understand our script injection, Right-click, select “View Page Source,” and then search for the above-injected script code.

The script code was injected as it was given. This confirms we could inject the malformed script code in the user input field.

Revisit the following page: http://localhost:8066/ch01.php. Observe the popup message will be displayed again.

This is what a stored cross-site scripting vulnerability is. Once the malformed input is injected, it will be executed every time the page is loaded. If multiple users are using the same application, then the script code will also be executed for each and every individual victim as well.

Attackers can use the above type of functionality to deface the page and completely change it based on malicious intent using JavaScript and HTML code. Similarly, write a malicious piece of code to steal all the authenticated users’ session tokens and reuse it for accessing the user’s account without passwords. Or even redirect victims to a malicious page, etc.

🎉 This type of behavior is called Stored Cross-Site Scripting vulnerability. Yay! We found a stored cross-site scripting vulnerability and solved XSS Challenge 1.

About XSS Payloads

The above example demonstrates a simple XSS code snippet.

You might be wondering how I would ever be able to create those script payloads, and I am not even familiar with JavaScript and that stuff.

Well, lots of security researchers have already done most of the work related to payloads for you. You all need to know when to use it and what needs to be changed based on your scenario. As the experience grows, you will be able to write your own custom payloads for yourself.

Here is a repository of “PayloadsAllThings” that you might need to bookmark it.

You will find a lot of information on different vulnerabilities and their payloads. Just search for “XSS Injection”.

Go ahead and try out with a wide range of XSS payloads and see how the application behaves.

💡Practice Makes perfect.

Clean up - XSS Data

It might become annoying if we keep getting too many popups, which can even impact usability.

Click on the “Purge Database” button to eliminate the annoying popups and start fresh.

Conclusion

I hope you learned about the different types of cross-site scripting vulnerabilities. Organizations are using the most secure coding frameworks and best practices, but they might still miss out due to complex application ecosystems, which can give way to XSS vulnerabilities. The above example demonstrates how improper coding practices can be used to exploit stored XSS vulnerabilities, and fixing them as soon as possible as part of security assessments can reduce the huge impact on production systems.

If you haven’t installed the Burp Suite, refer BurpSuite Installation and ensure the tool is successfully installed.

Overview

Let’s launch the BurpSuite community edition using the steps from BurpSuite Installation guide.

At launch, the “Learn” tab will be selected and all the information required for learning and using the tool will be displayed as shown below. You can always explore the text and video tutorials provided by the tool.

Dashboard

A place where you can see information about the crawling and issues identified.

Tasks section is a place where we can configure crawling for all websites we visit and keep an eye on their status. By default, the tool helps us by enabling “Live passive crawl”.

Passive crawl means when I visit any website using the Proxy tool, it starts looking at all the HTML content and collects page URLs, parameters, etc. keeps building the sitemaps locally for our knowledge base.

This is similar to the daemon service, it will keep on continuously running from the start of the BurpSuite tool, you can disable it by setting the “Capturing” off.

Event Log section gives you information about the BurpSuite tool itself like services started, error information if it is unable to load any extender plugin, network issues, and warning about the tool which might impact your work.

Issues Activity is a place where the BurpSuite scanner will display all the vulnerabilities identified by the tool

Issues Information section where you can see a detailed description of the security bug reported and the proof of concept of how the tool was able to identify it as a security defect.

The above issues sections are only available in the BurpSuite Professional edition.

Target

The target tab consists of three items, site map, scope, and issue definitions.

Site map is the place where you can see all the URLs, and parameters information collected by the crawler. As we can only see the status in the dashboard, here you can find the detailed information post crawling of websites.

Scope is the most important section while performing any security assessments or pentesting.

Be very clear about which particular websites are part of your scope for security testing, and add them to the “In Scope” section. (Example: securityarray.io as in scope)

Anything which is not supposed to be tested on a particular website excludes all of them from testing by adding it to the “Out of Scope” section. (Example: payments.securityarray.io)

Always keep in mind, that only perform security testing on the scope mentioned to you. Violating the terms and conditions of the scope of your assessments will lead to banning you, or sometimes you might face legal challenges from the owners of the website.

Issue definitions are like a vulnerabilities inventory of BurpSuite about all the vulnerabilities it can identify. The security defects are all categorized from informational to High severity.

This is also a good place to keep referring to vulnerabilities information.

Proxy

This is the core feature of the BurpSuite tool.

In short, once you configure the BurpSuite proxy with your web browser, Any traffic which goes from your web browser to the web server will be viewable in your BurpSuite proxy tab.

Not only view, but you can also intercept and modify any request before it goes to the server.

Generally, the browser limits our capabilities to only view the HTTP messages for debugging purposes, by using this proxy tool as an intermediate you can overcome those limitations

In security, we often keep on saying “Validate every piece of data which is coming from the client side”. As it can be tampered with.

After launching the BurpSuite tool, the first thing to ensure your proxy listener is started and in a running state.

Navigate to the “Proxy” tab ⇾ “Options” ⇾ “Proxy Listeners”. As shown in the above screenshot.

HTTP History is a location where all the ongoing HTTP traffic information can be viewed.

Intercept tab is where you have the option to enable for all or each request you want to change before sending to the web server, or turn it off if you don’t want to modify any requests.

By default, the intercept feature is enabled at startup.

Navigate to the “Proxy” tab ⇾ “Options” ⇾ “Intercept Client Requests”. As shown in the above screenshot.

You would be able to see the Intercept requests enabled, and the rule set of what all requests the Burp Proxy will intercept.

Similarly, we can enable the intercepting of responses as well if you want to see it in the proxy itself.

Additionally, the Intercept tool also does contain an inbuilt Chromium browser which is preconfigured.

Launch the browser and start accessing any website, you should be able to see all the data being seeded into your BurpSuite Proxy.

In short, the takeaway from the proxy tool is to configure with any web browser, and we can start playing with the requests sent from the client to the server.

Intruder

This is one of the best features of the BurpSuite. Let’s say you are having a situation where you need to test whether the application is using the default username and passwords for the server.

Yes, we do consider it a security bug if you use the default username and passwords on the server. Because anyone on the internet can guess it.

If our list of default usernames/passwords is less than 10, probably you can do it manually. But what if it’s 100+ and beyond?

BurpSuite intruder is a big savior here. All, we need is to load the HTTP request, choose where you need to inject the modified values, set the payloads list (usernames or passwords list), and fire. That’s it!

Intruder itself is a very big concept, which we will be covering in upcoming articles.

For now, all you need to remember is we can fine-tune custom payloads and reduce our manual efforts at the time of security testing for various scenarios using intruder.

Repeater

Based on the tab name, you could have probably guessed it is used to send repeated instructions!

For example, you are testing a Password Strength functionality where you need to check if accepts only small characters, or only numerics or passwords with lengths less than 5, etc.

Here, we can do this from a web browser by accessing the application interface. But, don’t you think it’s too repetitive to always reload the page and enter a value, click submit and observe results?

Yes, the repeater saves us a lot of time. Just capture any request message and modify it before sending it to the server. You can see the response in the repeater tab itself. This saves us a lot of time when sending repeated requests.

Sequencer

As the name suggests, it is used to analyze a large sample of tokens to see whether it is predictable or completely randomized and unpredictable.

In general, this is used for analyzing the session tokens to find if it is predictable. If you can predict what the next session token will be set by the server, then this is considered a security flaw.

Live capture helps you to capture each request directly by interacting with the web server. Whereas Manual load is a place where you can give samples of the tokens you have collected for analyzing the strength of the tokens.

Decoder

You encountered a type of encoded hash and are not sure what type of hash it is and how to decode it during assessments. We even have a way to decode/encode it using the decoder tool.

Start by using the “Smart decode” option, which will figure out the type of encoding and decodes it to plain text.

BurpSuite decoder currently supports URL, HTML, base64, ASCII hex, hex, binary, octal, and GZIP encodings as of today.

Comparer

Comparer lets you view the differences between the two messages of what was modified and what was added newly.

Logger

Logger displays all the communication information between your BurpSuite tool set and the target website.

Extender

BurpSuite extender gives additional superpowers to expand the capabilities of the current toolset.

BAppStore is a list of plugins inventory that is provided by portswigger as well as from the security community.

APIs provide us the capability to add custom functionalities based on requirements.

Extensions tab provides you with information about all the extensions which are enabled and their output.

Project options

Let’s say I want to automate the set of sequential operations which need to be performed with less manual effort. Can I do it?

Yes, you can do that using Macros.

Project options provide you with a lot more benefits to tweak session handling rules, how and where the cookies are maintained, Macros to repeat a sequence of actions based on rules, HTTP communication preferences, etc.

To save all the changes, navigate to the “Project” menu item ⇾ select “Project options” ⇾ “save project options”.

Similar way, you can load the saved options using “Load project options”.

User options

These are settings specifically for the user who uses the BurpSuite.

Some options where we are tweaking repeatedly while launching BurpSuite, probably there is a way to save that setting and use it whenever you launch the tool rather than configuring it every time.

Say, you want to change the Interface to how it looks better for you or update shortcut keys, change temporary file location, update communications information, etc.

All about how you want the tool to behave can be updated here.

Lastly, to save all the changes, navigate to the “Burp” menu ⇾ select “User Options” ⇾ “save user options”. Using the same way, you can load the saved options using “Load user options”.

Summary

Well, we have covered a good amount of information about the different sections available in the BurpSuite tool.

I hope, by now, you are familiar to navigate and choose different tabs based on requirements.

Introduction to HTTP and its importance

HTTP, which stands for “Hypertext Transfer Protocol”, is the foundation used for data communications on the World Wide Web. In simple words, this protocol lets communication between our web browser and web servers.

Understanding the HTTP is crucial for anyone who is interested in getting into security testing. It is a basic foundation for all the data communication on the internet. Knowing about the HTTP Requests, Responses, and Status Codes will help us to understand more about a web application and its behaviour during the security testing process and even help us automate repetitive manual work.

What is HTTP?

HTTP is a protocol with a set of defined rules for communicating between the client and the server. Think of it like this: we humans use a common language to speak and communicate with each other. Similarly, the protocol is to communicate with the client (Example: Web Browser) and the server (Example: Apache HTTP).

Our modern web browsers hide this complexity by taking care of them and loading beautiful web pages for us to be easy to read and understand.

💡On the web, all I see is HTTPS. Yes, you are right. The working principle is the same, with few changes. Will cover those as well.

HTTP is text based protocol

HTTP is a simple message-based request/response protocol. When the user requests a web page, the browser sends the HTTP request to the server in the background, which then responds with the requested resources. The website responds back with the requested resource, which is called response.

HTTP acts as a medium through which information is exchanged. It allows the transfer of various types of data, including text, images, multimedia files, etc.

Structure of HTTP Requests and Responses

A sample of HTTP request-response can be seen as shown below:

Request:

Response:

I can see this is a lot of data to digest, don’t worry, with the overwhelming information you see on the response screenshot. You don’t need to remember everything. This is to get you acclimated to the type of data you’ll see from now on and focus only on what we need the most.

We will come back to technical in a bit. Let’s go ahead and learn more about HTTP.

HTTP is a Stateless Protocol

As the name suggests, the stateless protocol does not maintain the state of a transaction. Stateless protocols are typically used in low-level communication applications, where data packets can be sent without any notifications. An example of a stateless protocol is TCP.

This means you get the response back once a request is sent and the connection closes. It will not be able to link or relate to any previous requests.

1. Example of HTTP/1.0 and below versions

   $nc demo.testfire.net 80
   GET / HTTP/1.0
   Host: www.demo.testfire.net
   
   HTTP/1.1 200 OK
   Server: Apache-Coyote/1.1
   Set-Cookie: JSESSIONID=DF622CC21A2727AC5DD745D1A5B007BF; Path=/;
   HttpOnly
   Content-Type: text/html;charset=ISO-8859-1
   Date: Wed, 27 Jul 2022 07:48:18 GMT
   Connection: close
   

   I am using a tool called net cat (nc) here to demonstrate a stateless example by sending the custom request and waiting for the response from the server. If you observe closely, the server sends the last line Connection: close.

   Connection: header above tells that the TCP connection can be closed once after sending the HTTP response.

   But from HTTP/1.1 and above, the TCP connection will not be closed and will wait for the next request to be received and processed.

   $ nc demo.testfire.net 80
   GET / HTTP/1.1
   Host: demo.testfire.net
   
   HTTP/1.1 200 OK
   Server: Apache-Coyote/1.1
   Set-Cookie: JSESSIONID=D7190756165E5E1B4986094B7A17630F; Path=/; HttpOnly
   Content-Type: text/html;charset=ISO-8859-1
   Transfer-Encoding: chunked
   Date: Wed, 27 Jul 2022 07:54:31 GMT
   

   In the above request/response, you can see the Transfer-Encoding: chunked, which means the connection is not closed, and it is waiting for the next request to process.

   Transfer-Encoding: header is used to specify the type of encoding used on the data sent in the message body in a series of chunks.

   For now, remember that the above concepts will be helpful while discussing advanced HTTP attacks.

   

HTTP vs HTTPS

HTTP (Hypertext Transfer Protocol) and HTTPS (Hypertext Transfer Protocol Secure) underlying working concepts are similar. HTTPS is a secure version of HTTP that uses SSL or TLS security certificates.

The HTTP protocol is outdated and not secure. The HTTPS protocol is more modern and has encryption codes to protect user information.

A few of the drawbacks of HTTP are detailed below:

1. HTTP transmits messages in clear text, meaning that anyone on the network can view all of your requests, responses, and sensitive information like usernames, passwords, and card information.
2. Not only above, if your data goes through any of the Proxy connections, then a copy of your request and response is also stored now on the proxy server. How the admin uses the information is beyond our control, and it would be hard to track the attacker.
3. In some browsers where the cache is enabled, the copy of your request will also be in the cache. This is challenging when the session token or sensitive information is passed in the URL.

This is where HTTPS protects us with privacy and integrity from all kinds of snooping or Man in the Middle (MITM) attacks.

Lastly, the default port for HTTP is 80, and HTTPS is 443. It can also be changed based on requirements.

Breakdown of the HTTP components

Let’s dig a bit deeper and learn more about the HTTP syntax, methods, and headers. This section helps us in reviewing request-response messages and confirm whether vulnerability exists or not.

Take some time to understand and get well acquainted.

HTTP Syntax

We came to understand that HTTP is a simple message-based protocol that contains request and response messages.

Let’s try to understand more about the request.

1. A Typical Request Message:

   

   HTTP request contains two sections, Headers, and Body. The header and body are separated by an empty line.

   The body section can vary based on the type of HTTP method. For example, the GET HTTP method doesn’t contain any body information, but the POST method does contain.

   • 1. Headers:

     POST /members/api/send-magic-link/ HTTP/2
     

     In the above line, the first one POST is called a verb. It’s one of the HTTP methods commonly used for posting data onto the server.

     Followed by the URL path members/api/send-magic-link, the page which the client is trying to access/post.

     Lastly, HTTP/2 is the protocol and its version used for communication.

     Each header in the message body is placed on a separate line. The next header is Host.

     Host: securityarray.io
     

     Host header contains the domain name of the server to whom the request must be sent.

     Next, followed by other headers.

   • 2. Body:

     HTTP Body section contains the additional supporting information for the above-specified POST header information. Below is an example of the JavaScript Object Notation (JSON) type of data passed to the server in the message body.

     {"name":"Raghu","email":"example@securityarray.io","requestSrc":"portal"}
     

     The message body can also be plain text or HTML or XML data based on the type of content being transmitted.

     A Typical Response Message

     

     HTTP Response message will look similar to the above, containing the Headers and Body separated by an empty line.

     HTTP/2 201 Created
     

     The first line specifies the server acknowledgement back to the client using HTTP/2 protocol, and the next 201 is a status code specifying the type of action taken by the web server for the request sent.

     Here, it has created the content on the server. Therefore, we received 201 Created.

     By this, I can confirm the content I have posted is created on the server, and it acknowledges back, followed by other HTTP headers and message body, and next if any.

     The HTTP message body is later beautified and displayed back to the user on a web browser in a human-readable way.

     

HTTP Methods and Its Purpose

The methods indicate the purpose for which the client has initiated the request and what is expected by the client to consider it a successful result.

Let’s walk through the different HTTP methods available.

1. GET is used to retrieve the resource from the web server, and it doesn’t contain a message body. The URLs that you observe in the browser URL bar are all GET requests.
2. HEAD is very similar to the GET, but it only sends the header section.
3. POST method performs a specific operation with the provided message body. Like creating or updating. It is recommended to use POST for sending sensitive information like username, password, card info, etc. As the message body cannot be seen by intermediate resources like proxies.
4. PUT is most commonly used for updating the data and also for uploading the content to the server.
5. DELETE is used to remove a resource on the server, which is allowed only for users with authorized privileges.
6. CONNECT is used to establish a tunnel to the server
7. OPTIONS is used to request a list of HTTP methods enabled on the server.
8. TRACE is used for diagnostic purposes. Whenever you send a request using TRACE, you should be able to see the same contents in response as were sent in the request.

Understanding HTTP Headers

In HTTP, there are many headers, each intended for a specific purpose. We will be covering some headers, and if you would like to learn about the complete list of headers, the best source is RFCs (HTTP/1.1, HTTP/2)

Some headers you can observe in both Request and Response are given below.

Content-Length specifies the length of the message body in bytes.

Content-Type specifies the type of content present in the message body.

Request headers

User-Agent specifies the information about your browser or from other clients from which you are trying to access the web server.

Origin is used to specify from where the request originated.

Referer is used to specify the request from which the current URL originated.

Authorization is a token used to pass to the server for accessing privileged resources.

Accept headers inform the server about content types accepted by the client.

Accept-Encoding informs the server about encoding types understood by the client.

Response Headers

Set-Cookie is used to set the session cookies on the client side to identify the sessions and user accounts used for accessing server resources.

Access-Control-Allow-Origin indicates whether the resource can be retrieved via cross-domain Ajax requests.

Cache-Control passes the instructions to the browser about how the cache must be handled.

Decoding HTTP Status Codes

The status codes are used to inform the client about how the request was handled. The server acknowledges back with the three-digit numerical codes of how it was processed.

Getting familiar with status codes helps you to review and take action while performing security assessments.

Let’s look at common status codes which we will be encountering day-to-day.

100 Continue message sent by the server to continue and keep sending the message body. Once completed, the server will respond with another status message.

200 OK means that the request was successful and that the response body contains the result of the request.

201 Created is returned in response to a PUT/POST request to indicate that the request was successful and created.

301 Moved Permanently redirects the browser permanently to a different URL. So the client should use the new URL going ahead in the future.

302 Found redirects the browser temporarily to a different URL

304 Not Modified specifies the browser to use the cached copy as the client has the latest data of the server.

400 Bad Request is a client error that indicates that the client submitted an invalid HTTP request.

401 Unauthorized indicates that you need to be authenticated to access the server resource.

403 Forbidden indicates that you do not have privileges to access the resource on the server.

404 Not Found means the requested resource is not present on the server.

405 Method Not Allowed means the specified HTTP method in the request is not supported for the given URL.

500 Internal Server Error indicates that the server is unable to process your request, which might be because of some unhandled error within the server application.

503 Service Unavailable is displayed when the server is handling a heavy load and is not able to function. Also, during maintenance hours, or during migration, or even in case the server crashes.

Conclusion

I hope this short tutorial has provided the foundations for understanding HTTP protocol and its significance in terms of application security. It’s a lot of information to digest and remember. You could use this as a reference to get started, and surely, this is going to help us make better decisions while carrying out security assessments.

I encourage you to continue exploring the HTTP RFCs (HTTP/1.1, HTTP/2, HTTP/3) for in-depth understanding.

Remember, learning web application security is an ongoing journey, and each step you take brings you closer to mastering this valuable skill.

Keep exploring!

In this article, we shall learn about the reflected XSS and how it differs from the stored XSS.

Before we start, ensure the lab is running if you have not set up your lab yet.

Types of Cross-Site-Scripting (XSS)

How Reflected XSS Work?

The server processes the malicious input code supplied from the client side, and the same malicious code is injected and then returned to the client in an HTTP response without proper validations.

The browser renders the response content, assuming it was supplied by the application server, which can be trusted, and the injected malicious code also gets executed.

The significant difference that can be observed when compared to stored cross-site scripting is, in reflected XSS, the malicious code is just appended back in the HTTP response and executed immediately. It is not stored anywhere in the database.

For the same reason, the impact of reflected XSS is reduced compared to the stored cross-site scripting vulnerability.

Practicals - Reflected XSS

Post setting up the lab, visit http://localhost:8066. The application should be loaded as shown below and Navigate to “XSS Challenge 2.”

Before you start assessing, take some time to understand how the application functionality works.

Let’s go ahead and give it a try with the similar payload used in the stored XSS.

Once appending the payload, click the “Submit” button, as shown in the screenshot below.

Immediately observe the alert pop-up message, which will be displayed below.

Click “OK” and observe the page loads normally.

To verify and confirm the vulnerability, right-click and select “view page source” and search for the above-injected payload.

The proof-of-concept script code aligns correctly with the HTML response received, and all the characters are displayed back as given in the input field.

Yay!! Now, we can confirm we have successfully exploited the reflected XSS.

Now, a point to remember here is that as this is not stored in the database, it gets executed only when the malicious code is injected. At all other times, the application usually behaves as expected.

In Stored XSS, the malicious payload gets executed whenever any user visits the injected application functionality.

Summary

This article covered how to identify reflected XSS and how it works, including reusing the same XSS payload without much tweaking.

Keep learning!! :D

Before we start, ensure the Kurukshetra lab is up and running if you have not set up your lab yet. Feel free to refer back to the below link.

We walked through stored and reflected XSS in a previous couple of articles. In today’s article with those foundations, let’s dive into the practical labs and start learning.

Practicals - Reflected XSS

Post setting up the lab, visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 3”.

Let’s try it with the XSS payload used in our previous articles and observe how the application behaves.

Payload Try 1: Classic

Output:

From the above observations, the application no longer gives pop-up messages but instead prints out the partial string from our given payload. Which indicates that our XSS payload is no longer working.

To evaluate further, click “View page source” to understand how our injected payload string is loaded in the HTML response body.

I can see that there is some kind of filter kept in place by the application that removes the word “script,” which breaks the HTML syntax, and the browser treats the following data as just text and displays back the partial string.

Can we assume that the vulnerability is fixed? No

The developer leveraged a technique called “Blacklisting” to secure the application from exploiting the XSS vulnerability. However, this approach has limitations, and it can still be bypassed.

1. TIP - 1

   HTML is case-insensitive, which means we can try it by changing it to upper case or small case letters or even combining small and upper case letters together, as given below.

   

Payload Try 2: Case-Insensitive

Output:

It looks like this technique also failed. The application seems to be filtering out the lowercase and uppercase script tags that were inserted.

1. TIP - 2

   Javascript functions can be triggered for execution in multiple different ways, not necessarily that only the HTML script tag is needed all the time.

   One of the ways to execute the javascript “alert()” function is using the HTML SVG tag, which is generally used for loading the vector graphics file on the HTML pages.

   Example:

   

   The HTML Attribute “onload” is one of the special words used to control the behavior.

   In the above example, the HTML attribute “onload” is assigned to a javascript function “alert()” which runs immediately when the HTML SVG tag is loaded.

   Let’s go ahead and check out the things in action.

Payload Try 3: HTML5 Tags

Output:

This attempt also failed, as the application filters out multiple HTML tag strings. i.e., svg, script, img, etc.

From the above example, we can see that the HTML attribute “onload” is being loaded without any filters and displayed back as keyed in.

1. TIP - 3

   Not all HTML tag strings can be blacklisted. Some might break the entire HTML page itself and application functionality.

   For example, the HTML Body tag is needed most to load the page’s content. HTML Style tag, which is used to beautify the page, etc.

   We shall improvise the previously used payload with the HTML Body tag.

Payload Try 4: HTML5 Tags

Output: pop-up message

yay!!! 🎉 This time, our XSS payload worked, and the application displayed the pop-up message.

To further confirm, Click “OK,” then right-click and select the “View page source” code to see how our payload was injected and aligned with the HTML response code.

You should be able to find out that our injected payload is rightly aligned, HTML attribute onload event is triggered immediately. Therefore it indeed executed the javascript code.

Through this, we have successfully solved the XSS challenge 3.

Summary

In this article, we learned how poorly implemented validations can still be bypassed by improving the payload and trying different possible combinations. The blacklisting approach is helpful for a quick fix but is not foolproof, which must be updated whenever a new payload has been reported. Additionally, we covered many tips and techniques that can help you improvise your XSS identification skillset.

Keep learning!! :D

What is Wordfence?

Wordfence is a security plugin for WordPress that helps secure your website from various online threats. It has an application firewall, malware scanner, and many other features designed to keep your website safe and secure. With over 5+ million active installations, Wordfence is one of the most popular security plugins for WordPress.

Key features and benefits

• Application Firewall: It has a web application firewall that can identify and block malicious traffic before it reaches your website.
• Malware Scanner: The plugin scans your website for known malware and helps keep your website free from viruses.
• Brute Force Attack Protection: Wordfence helps protect your website from brute force attacks by rate-limiting login attempts and enforcing strong passwords.
• Two-Factor Authentication: The plugin also offers two-factor authentication, an extra layer of security for admin user accounts.

Pre-Installation Steps

Before installing Wordfence, it’s important to take a few pre-installation steps to ensure a smooth and secure process.

In this article, we will focus only on the free version of Wordfence.

Backup your WordPress website

It’s always a good practice to create a backup of your WordPress website before installing any new plugins. This ensures that you can restore your website to its previous state in case anything goes wrong during the installation process.

Update WordPress and all plugins

Ensure your WordPress core installation and all other plugins are up to date. Running the latest versions of WordPress and plugins helps ensure compatibility and security.

Installing Wordfence

Log into your WordPress admin account, navigate to “Plugins” -> “Add Plugins”, and search for “Wordfence”.

Getting Wordfence License

After installation, click on the “Activate” button to ensure the plugin is enabled. You will see a page stating that the plugin has been successfully installed and requesting that you “Get your Wordfence license.”

Even to access the free features of Wordfence, we need to register with a valid email address to get the activation code.

It will take you to the Wordfence website, where you can choose from the different packages offered by Wordfence.

In our case, for demo purposes, we shall go ahead with the “Free” license that is available.

Wordfence requests you to re-confirm and highlights that you will be missing out on the latest exploit protection in real-time.

The malware scanning rules are updated monthly in a free version, and Real-time protection is available in a premium version.

You can try it with the free version and upgrade it based on your requirements. For the demo, we go ahead with a free one.

I have no association with Wordfence, just for educational purposes.

Click on “I’m OK waiting 30 days for protection from new threats” to continue.

Enter your email address. Subscribe if you would like to receive the latest information about the vulnerabilities and check the terms and conditions. Then click on the “Register” button.

Activating Wordfence License

Next, you will receive an activation link and instructions for setting up the plugin.

Click on the “Install My License Automatically” button. The license information will be automatically filled in on your WordPress website (if you are logged in).

Click on the “Install License” button. By this, we have successfully installed the free version of WordPress. A confirmation dialog will be shown below.

Wordfence Dashboard

Click on the “Go to Dashboard” button, and it will take you to Wordfence Dashboard.

Finally, the “Wordfence Protection Activated” on your website with standard recommended settings.

Just make sure to enable the “auto-updates,” so you don’t need to update every time manually.

Wordfence Scan

When you install the Wordfence plugin, the standard scan options are enabled, which is good enough to enable standard security features for your site. In the above Wordfence Screenshot, click on the “Manage Scan” link.

As covered above, the “Standard Scan” is enabled once you activate the “Wordfence” plugin.

Additional options, like “High Sensitivity,” can be used to scan and check if you think your website might be compromised. You can always click on the “All Options” link on the left side menu and check the settings that have been enabled.

Go ahead and scan your website for security risks. 😃

I hope the above information is helpful in securing your site. I will be coming up with options to harden your WordPress website soon.

Wordfence Help

Check out the Wordfence site for more help information.

Wordfence Help Center

Conclusion

Securing the WordPress website is an important factor for website owners. With the increasing attacks on WordPress, proactive measures like this help secure your online assets.

Wordfence is a feature-rich WordPress security plugin that is available for free. It provides a wide range of features to enhance your website’s security, such as checking for malware, firewall protection, Two-Factor Authentication, etc.

You will be able to see the security posture of your WordPress Site. Don’t wait until it’s too late. Enable it now to reduce security attacks.

Understanding the Importance of Vulnerabilities Scans

In today’s digital age, the attack landscape for WordPress sites is constantly evolving. Cybercriminals are always looking for new ways to exploit vulnerabilities and compromise the security of websites. As a WordPress website owner, securing the business and customer data hosted on your website is crucial.

Below are statistics of the most infected CMS websites in 2022 by Sucuri.

Evolving Landscape of WordPress Vulnerabilities in Cyber Security

Cyber threats are becoming more sophisticated than ever. Coming to WordPress, new vulnerabilities are primarily discovered in third-party plugins, and some are in themes and WordPress core. Attackers leverage these vulnerabilities to gain unauthorized access to your website, spread malware, steal sensitive information, or even disrupt the functionality of your site. As a result, proactive measures can help you to address these vulnerabilities before they are exploited.

Below are statistics on vulnerabilities based on WordPress components by wpscan.

Risks of ignoring security measures
Ignoring security measures for your WordPress site can have severe consequences. A compromised website can lead to a loss of customer trust, damage to your brand’s reputation, and potential legal and financial implications.

Additionally, the time and resources required to recover from a security breach can substantially impact your business operations and revenue.

Benefits of proactive vulnerability scanning
Proactively scanning your WordPress site for vulnerabilities offers several benefits.

• It allows you to identify and address potential security risks before malicious actors exploit them.
• Vulnerability scans also help you maintain compliance with security standards and regulations.
• It demonstrates your commitment to protecting user data and maintaining a secure online environment.

Choosing the Right Tools or Plugins for Vulnerabilities Scans

When performing vulnerability scans for your WordPress site, choosing the right tools or using the recommended security plugins is crucial. Going ahead, I will cover different options available to scan a website for security flaws. Pick the one that matches your requirements and capabilities.

Popular vulnerability scanning tools

There are numerous vulnerability scanning tools and plugins designed specifically for WordPress security. Some popular options include plugin-based software such as Jetpack Protect, Wordfence, Sucuri Security, Shield Security, etc. Advanced scanners like Nuclie Scan, WPScan, CMSeek, etc. These tools offer varying levels of security by helping you detect vulnerabilities, malware scanning, firewall protection, and security hardening, and even about how to address vulnerabilities.

For this post, our scope would be limited to identifying vulnerabilities using various tools and taking necessary action based on identified findings.

Factors to consider when selecting a scanning tool or plugin

Below are some of the factors that can help select a WordPress security scanner, i.e. plugin based or online tool:

• How frequently is the vulnerability database being updated?
• What level of support and documentation is available?
• Does the tool offer additional specific features like securing login, APIs, enabling firewalls, notifications, Two-Factor Authentication, etc?
• What is the expected budget vs the tool cost structure?
• How effective is it in identifying the vulnerabilities?
• Does it support automation and regular interval scans?
• How many of your websites need to be protected?
• How big is your application, and how many custom-coded functionalities are used?

Above are a few points that help you to select the one that aligns with your website’s security needs. It’s important to choose a tool that provides comprehensive scanning capabilities and is regularly updated to address new threats.

Comparing free vs. paid scanning options

While most examples covered in this article will use the free vulnerability scanning tools available, it’s important to weigh the benefits before investing in a paid solution. Paid options often provide advanced features, dedicated support, and enhanced protection, making them a worthwhile investment for the security of your WordPress site.

Preliminary Steps Before Performing a Vulnerabilities Scan

Now that you understand the importance of vulnerability scanning, the most important step is to ensure your data is safe and ready to restore at any point in time. 

Backup all your WordPress site

Before carrying out any security checks, the first thing to do is to ensure that a complete website backup is taken and can be easily restored. This precautionary measure will be helpful in case any unexpected issues arise. Therefore, data integrity should never be compromised.

Additionally, the backup should be hosted on a separate server, different from the one where you are performing the security scan.

Update your WordPress site before the scan

In most cases, a simple solution to fix the vulnerabilities would be to update the plugins, theme, and WordPress core. Of course, if you have customized any of the code, you might need to check the compatibility before updating.

This step can save efforts and can avoid dealing with vulnerabilities to which the vendor has already provided patches. Therefore, our results will be more accurate.

Step-by-Step Guide to Perform Vulnerabilities Scan

In this section, we will explore a variety of WordPress vulnerability scanners (i.e., free or partially free) that are readily accessible on the Internet. We will begin with those that are easy to use and then move to advanced CLI scanners.

I have no association with any of the tool vendors that are used below. All the information provided here is only for educational purposes.

Using WPSEC: Automated WordPress Scanner (Online)

WPSec is one of the WordPress security scanners out there on the internet. You can perform a WordPress vulnerability scan online. There is no need to set up any tools. Start right with the scan.

WPSec is an automated tool that instantly scans your WordPress website for vulnerabilities. It is an advanced vulnerability scanner that utilizes WPScanner and custom technology to continuously update its database with the latest security features and bug fixes.

The tool offers both free and paid plans. For demo purposes, we will use a free plan.

Remember to scan only the website you own or have written permission to.

Visit the site https://wpsec.com, provide the URL of the WordPress website that you own, and click on the “Start Scan” button. I will be using my test website as an example here.

It takes a few minutes or less to scan the site, and it immediately displays the risk information if your website contains any vulnerable WordPress components.

On my website, I can see that it displays the message “Your WordPress website is vulnerable to attack!” and the Risk Factor is 1.8, which indicates that security flaws exist and can be used to compromise the site.

To access the vulnerabilities report and to carry out regular interval scans, one must register using a valid email address of the same domain. You can give an email address and click the “Send” button to complete the “Sign Up” process.

Upon successfully logging into the application, authenticated users will have a dashboard displaying the total number of WordPress sites added to their WPSEC account.

On the left side of the tab, click on the “View Reports” link as displayed below.

From the above screen, we can see that my site status is displayed as “Vulnerable” and can see the scan reports in web, PDF and JSON formats. Only “web” reports are available in the free edition, and another type of report would require you to upgrade to a premium account.

Click on the “Web” report and scroll down to the “Plugins & Themes” section, where you can find the information on identified vulnerabilities that could potentially impact the site.

Toggle on the “WP-Booking-System” vulnerable plugin highlighted in red, and the additional vulnerability information is displayed. It displays the “Reflected Cross-Site-Scripting Vulnerability” present in the plugin being used.

Just click on the link, and it will take you to another page displaying more detailed information about the vulnerability and proof of concept (POC) on how it can be exploited.

From the security analyst’s point of view, the above information can help to verify and confirm the vulnerability.

Attackers use the same vulnerability by modifying the above code to redirect genuine users to a malicious website, steal session cookies, to log keystrokes, for phishing, etc.

From a website owner’s perspective, Based on the above recommendations, the following vulnerability can be fixed by upgrading the “WP-Booking-System” plugin to its latest version, i.e. “2.0.15”. Therefore, we must update the wp-booking-system plugin to the latest version to avoid security impact.

Identify similar security vulnerabilities early and fix them as early as possible. If you use the custom code, make sure the code is patched as per recommendations.

Scheduling is one of the built-in features offered by the WPSEC in the free version, which you can continuously monitor and get regular updates about the vulnerabilities found.

To verify, navigate to the “Schedule” section and ensure the regular scan frequency is set to “Weekly". 

One of the things I found about this tool is it reported fewer vulnerabilities compared to other tools. We need to wait and watch if more coverage will be addressed in future scan results.

You could repeat the steps you learnt to find WordPress vulnerabilities on your websites.

Using Jetpack Protect: WordPress Malware and Security Scanning (Plugin)

A WordPress plugin that can help you scan for malware and security vulnerabilities associated with WordPress Core, themes and plugins.

This would be the second tool that we would be using to scan for WordPress threats.

The Jetpack Protect plugin differs from the Jetpack plugin and is offered separately by the Jetpack team. It is important to note that there is no dependency between the Jetpack Protect plugin and the Jetpack plugin.

The plugin is simple and easy to use.

Jetpack Protect is a totally free plugin that uses the data from WPScan. It is one of the most popular tools used in the security industry to carry out vulnerability scans on WordPress websites.

Let’s jump right into setting up the plugin.

Log into your WordPress website admin dashboard, Navigate to the plugins section and click the “Add New Plugin” button.

The website loads a plugin page and displays all commonly installed plugins.

Search for the “Jetpact Protect” plugin and click on the “Install Now” button.

Ensure that you install the plugin offered by the “Automattic - Jetpack Security team.”

Once installed, click on the “Activate” button as displayed above.

After activation, you will be taken to a subscription page. For demonstration purposes, I will click on the “Start for free” button to go ahead. Feel free to explore the premium options as well.

Once activated, it will immediately start scanning your site for vulnerabilities. It might take a couple of minutes.

After successful completion, all the identified threats are displayed, as shown below.

The plugin identified 29 threats on my website, listed above in detail. Additionally, the summary information about each threat is displayed on the right side, which helps you take the next action needed to secure your site. 

It also displays a green checkmark for plugins, themes, and core if they are free from threats. 

Jetpack Protect even allows you to set up a “Firewall” for your site; feel free to explore. I have just enabled the Firewall to prevent the brute force attacks on my site’s login page, as shown below.

The Jetpack protect plugin is one of the effective ways to secure your website. The plugin is well-suited for website owners because of its simplicity and ease of use.

WPScan CLI

Using the Jetpack plugin is a good option when you have admin access to the WordPress website.

WPScan CLI will be used for one-time scans or security assessments. The advantage of a CLI scan is that it can be used to perform specific checks based on the use case, such as checking only for vulnerable plugins or themes, leaking usernames or config backups, etc.

Its installation is straightforward. To set it up locally, you can use the gem package manager, docker, or brew. Check out WPScan Installation.

As I have a Gem installed on my system, I will use the Gem to install it.

WPScan CLI Installation: (Using Gem)

gem install wpscan

Output:

Fetching public_suffix-5.0.5.gem
Successfully installed public_suffix-5.0.5
Successfully installed wpscan-3.8.25
Parsing documentation for public_suffix-5.0.5
Installing ri documentation for public_suffix-5.0.5
Parsing documentation for wpscan-3.8.25
Done installing documentation for public_suffix, wpscan after 0 seconds
2 gems installed

The WPScan CLI tool uses the WordPress Vulnerability Database API to retrieve WordPress vulnerability data in real-time. The –api-token option requires supplying an API token, which can be obtained by registering an account on WPScan.com.

You can use the CLI tool without an API token as well. Only the vulnerability information will be missing.

WPScan CLI - The free plan allows 25 API requests per day, which would meet our requirements. I have already obtained my API token.

WPScan using CLI

$ wpscan --url https://wptest.securityarray.io/ -e vp,vt --plugins-detection mixed --api-token $WPSCAN_API_TOKEN

• “–url”: The target website to scan for vulnerabilities.
• “-e”: Enumerating only for vulnerable plugins and templates.
• “–plugins-detection”: Using both passive and aggressive ways to detect valid plugins on the website.
• “–api-token”: Stored WPScan API token in environment variables and used it for the scan. (You can directly place your API Token Here).

Output Log (Log is stripped.)

[+] URL: https://wptest.securityarray.io/ [xx.xxx.xx.xxx]
...
[+] ninja-forms
 | Location: https://wptest.securityarray.io/wp-content/plugins/ninja-forms/
 | Last Updated: 2024-03-29T15:38:00.000Z
 | Readme: https://wptest.securityarray.io/wp-content/plugins/ninja-forms/readme.txt
 | [!] The version is out of date, the latest version is 3.8.2
 |
 | Found By: Known Locations (Aggressive Detection)
 |  - https://wptest.securityarray.io/wp-content/plugins/ninja-forms/, status: 200
 |
 | [!] 2 vulnerabilities identified:
 |
 | [!] Title: Ninja Forms Contact Form < 3.8.1 - Publicly Accessible Form Submission Export via CSRF
 |     Fixed in: 3.8.1
 |     References:
 |      - https://wpscan.com/vulnerability/9107e702-e5ef-4328-8265-2a6b98092b3a
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-2113
 |      - https://www.wordfence.com/threat-intel/vulnerabilities/id/3ebfc9f5-abb7-47bc-bd38-f60df1cccb5d
 |
 | [!] Title: Ninja Forms Contact Form < 3.8.1 - Author+ Stored XSS
 |     Fixed in: 3.8.1
 |     References:
 |      - https://wpscan.com/vulnerability/c89ce032-c361-49e2-8ed0-c806bf399d96
 |      - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-2108
 |      - https://www.wordfence.com/threat-intel/vulnerabilities/id/6a6eb430-cf86-4e13-a4f7-173fada9fddf
 |
 | Version: 3.8.0 (80% confidence)
 | Found By: Readme - Stable Tag (Aggressive Detection)
 |  - https://wptest.securityarray.io/wp-content/plugins/ninja-forms/readme.txt

...

The scans will take a few minutes to complete, and once they are completed, you can check the identified vulnerabilities displayed above.

Using Wordfence Security Plugin

Like Jetpack, Wordfence is another security plugin with many more features that can help scan your WordPress site for known vulnerabilities and malware.

Check out the below bookmark to learn more about the WordFence Security Plugin.

How to Install Wordfence

Offline Tools

In this article, we covered a couple of WordPress vulnerability scanners that are user-friendly and beneficial for website owners. Moving forward, we will discuss one of the customizable vulnerability scanners commonly used by security professionals. Website owners can also consider trying it out for their websites.

Using nuclei: Customizable Vulnerability Scanner

Nuclei is a fast and customizable vulnerability scanner that identifies vulnerabilities based on the YAML-based rules. Nucli is a CLI tool built with Golang, and you would need a Golang installed to run from your local system.

Nuclei alone cannot find vulnerabilities, as it’s just an engine that runs any given rules. These rule sets are called as nuclei-templates. By default, the nuclei tool downloads the templates on the first run, so you don’t need to download them separately. Both nuclei and nuclei templates are open-source and freely available on GitHub. 

To keep things minimal, I will focus only on running the scans on my local demo website. To learn more about the installation and usage of the nuclei tool, check out here.

Default Nuclei Templates vs External Templates

Yes, we can run nuclei scans with the default templates. Default templates are the collection of community contributions with a wide range of vulnerability identification rule sets. Compared to the default one “nuclei-wordfence-cve” templates, which have more WordPress vulnerability identification templates that are taken from the Wordfence reports.

The effectiveness of the Nuclie scanner is directly tied to the quality of the nuclei-templates. The better templates you can find, the better the vulnerabilities. Some security professionals would prefer to write their custom templates.

Nuclei Scan with Nuclei Wordfence CVE Templates

Command:

nuclei -u https://wptest.local -t nuclei-wordfence-cve/ -o results.txt

• “nuclei” is the command used to trigger the scan.
• “-u” is the option used to specify the URL of a website which you want the tool to scan for. 
• “-t” is to specify a file or folder of templates that need to be used for scanning the given target.
• “-o” is to write the results output to a text file, which can be used further. Check out help information, as other types of results are also available.

Results:

The scan is completed, and a few critical, high, and medium-severity vulnerabilities have been identified on my website.

Command to run Nuclei with default templates

Command:

nuclei -u https://wptest.local -o results.txt -tags wordpress

• “-tags” is the command to run specific tag-based templates only. Here, in our command, I am using the keyword called “wordpress”.

From the huge list of default templates, only the WordPress-based templates will be loaded for scanning. Give it a try and observe how the vulnerabilities’ results differ.

Now, we need to take the CVE IDs and search across Google to find more about that vulnerability and how it can be exploited/mitigated.

For Example: CVE-2023-52134

Going through the search results, I will select the first one from the National Vulnerability Database.

Other Reference: https://wpscan.com/vulnerability/eef61b02-2f18-4140-9778-46e52a1664c4/

From the above description, we can understand that the vulnerability is in the improper handling of the SQL queries in the “geo-my-wp” plugin, which leads to an SQL injection and is fixed in version 4.0.3.

As part of the security assessment, it can be taken further ahead for exploitation or can be reported directly based on the version information.

We have covered a huge base of different ways to scan WordPress vulnerability scanners to help you get started in identifying vulnerabilities.

Addressing Vulnerabilities and Implementing Security Measures

Knowing about the common vulnerabilities in WordPress sites is essential for effectively addressing and mitigating potential security risks.

Interpreting the scan results

Once the scan is complete, review all the results and identify potentially impactful security threats. Start addressing all the critical ones that require immediate attention, then move to high severity, followed by medium and low vulnerabilities to secure your site. 

Implementing security measures to prevent future vulnerabilities

When addressing the vulnerabilities identified, follow best practices such as updating WordPress core, themes, and plugins.

Sometimes, we may not have the fix released by the vendor. This is where configuring a web application firewall is an additional line of defence to protect against common attack vectors.

In addition to addressing identified vulnerabilities, implementing security measures such as regular backups, SSL/TLS encryption, and security headers can help prevent future vulnerabilities and enhance the overall security posture of your WordPress site.

WordPress even offers to enable auto-updates of plugins, which can be updated regularly.

Enhancing the Securing of WordPress Sites

Check out the article below, which provides step-by-step instructions on how to secure your WordPress websites.

Enhancing the Security of WordPress Sites

Automating Vulnerabilities Scans for Ongoing Protection

To maintain a secure and resilient WordPress site, it’s essential to automate vulnerability scans for ongoing protection. The manual approach may not be feasible all the time.

The importance of regular and automated scans

Regular and automated vulnerability scans ensure your WordPress site is continuously monitored for potential security risks. By scheduling scans at regular intervals, you can stay ahead of emerging threats and proactively address vulnerabilities.

Utilizing alerts and notifications for immediate action

Configure alerts and notifications within your WordPress security scanner, if available. This helps you to receive immediate notifications of any identified vulnerabilities.  It allows you to address security issues and prevent potential exploitation immediately.

Analyzing your WordPress security needs:

Using WordPress security plugin (DIY)

Website owners who would like to do it themselves can use any WordPress security scan plugins to get started.

As the requirements grow or you need to handle sensitive customer data or when managing multiple websites that require dedicated time to focus on business, seeking professional assistance might be beneficial to reduce the potential impact of data breaches on your business. Here, you could opt for an online subscription or hire a professional service.

Seeking professional vulnerability management services

Professional vulnerability management services offer a wide range of expertise, advanced tools, and proactive monitoring to identify and address potential security threats, providing peace of mind and enhanced protection for your website.

Conclusion

The above information can help you empower yourself with proactive WordPress security scanning measures to maintain a secure and resilient website. For website owners, I would recommend to get started with Jetpack Protect. Security Professionals or Ethical hackers who want to conduct vulnerability assessments, starting with the wpscan and Nuclie scans, would be a good start. By understanding the importance of regular vulnerability scans, choosing the right tools or plugins, and implementing best practices, you can take control of your website’s security.

Additional References

Check out the bookmark below to learn more about the additional WordPress website security scanners online.

14 Best WordPress Security Scanners for Detecting Malware and Hacks - A comprehensive list of WordPress security scanners by WPBeginner.

Introduction to Bug Bounty and Pentest

In today’s digital landscape, where cyber threats constantly evolve, organizations increasingly turn to security testing, and we keep on hearing about the words bug bounty programs and pentests to enhance security measures.

Both bug bounty and pentest play crucial roles in identifying and addressing security vulnerabilities, but they differ in their approaches. Understanding these differences helps you choose which type of security testing best suits for organizations or hackers who want to get into security testing.

Bug Bounty Explained

What is Bug Bounty?

Individual organizations implement a program to reward external security researchers for identifying and reporting security bugs in their applications and systems.

This program helps organizations uncover the security gaps that haven’t been considered or missed in their security assessments. Addressing the reported security findings in the early stages helps to strengthen the organization’s critical applications and systems before malicious actors exploit them.

Depending on the organization’s policies, they even acknowledge and reward the researchers for responsibly disclosing the security flaws in their systems. The rewards might vary, like incentives, hall-of-fame credits, points, s, etc.

This process is also known as crowdsource security testing or Vulnerability Reward Programs (VRPs), which invites all independent security researchers around the world to participate in the program. This approach also enables organizations to tap into a global talent pool of cybersecurity experts and leverage their diverse skill sets to uncover potential security flaws.

How Bug Bounty Programs Work?

1. Organizations define the scope of their bug bounty program, which includes the systems, applications, guidelines, rewards structure, and types of vulnerabilities eligible for rewards.

2. Independent Security Researchers (aka Bug bounty hunters) then conduct security testing within the specified scope and report any discovered vulnerabilities to the organization’s security team.

3. Upon successful validation, the security bug is triaged. Post-triaging, the organization rewards the bug bounty hunter according to a predetermined bounty structure.

Remember, if everyone reports the same bug, only the first person to report will receive the bounty.

What are Bug Bounty Platforms?

A central hub that manages multiple organizations’ Bug Bounty programs and a pool of bug bounty hunters.

Bug bounty platforms bridge organizations and bug bounty hunters by establishing clear guidelines and policies for researchers, streamlining the vulnerability management process, facilitating efficient communication, timely resolution of reported security issues, and rewarding researchers.

They oversee the entire bug bounty program life cycle, making each party understand their roles and responsibilities in a well-organized and efficient way.

It’s a less hindering process for organizations and Security Enthusiasts who are getting started.

Examples: HackerOne, BugCrowd, Intigrity, Github

Refer here for information about more platforms.

Who can start a Bug Bounty program?

Any organization that decides to minimize security risks and secure its digital data from attackers can start a bug bounty program.

Currently, reputed organizations ranging from government entities, e-commerce platforms, software solutions, logistics companies, finance organizations, open-source programs, etc, all run bug bounty programs.

If you ever feel that managing security vulnerabilities is daunting, don’t hesitate to utilize Bug Bounty platforms. They are readily available to provide assistance and support.

Bug Bounty programs are instrumental in reducing unknown threats.

Examples: Google Bug Hunters, Meta (aka Facebook), Microsoft

Who can participate in a Bug Bounty program?

Well, there are no hard rules. Anyone with internet access having experience/interest in learning security testing can jump into the program and try it.

The Bug Bounty program is available for different security streams, web applications, mobile applications, binary applications, source code review, IOT, etc. Feel free to choose the one that is of most interest to you.

Key Features of Bug Bounty

• Global Talent Pool: Bug bounty programs allow organizations to access a diverse community of security researchers with varying expertise and perspectives.
• Continuous Testing: Bug bounty programs enable ongoing security testing, as researchers can continuously search for vulnerabilities, providing a proactive approach to security. 
• Cost-Effective: Organizations only pay for valid vulnerabilities identified, making bug bounty programs a cost-effective security testing solution.

Pentest Explained 

\

What is Pentest?

Penetration testing, often abbreviated as pentest or pentesting, is a simulated cyber-attack on a computer system, network, or web application to identify security weaknesses. This assessment thoroughly evaluates an organization’s IT infrastructure by deliberately attempting to exploit weaknesses in a controlled environment.

Penetration testing is conducted by the organization’s internal staff or in collaboration with reputable service providers in the market.

It aims to identify security gaps and provides actionable insights to improve the organization’s overall security.

Types of Pentesting

There are various types of penetration testing, including network penetration testing, web application penetration testing, mobile application penetration testing, etc. Each type focuses on specific areas of an organization’s IT infrastructure and applications, providing a comprehensive assessment of security vulnerabilities.

Key Features of Pentest

• Comprehensive Testing: Pentesting offers a holistic evaluation of an organization’s security posture by simulating real-world attack scenarios across different systems and applications.
• Controlled Environment: Pentests are conducted in a controlled environment, allowing organizations to manage the testing process and minimize potential disruptions to their operations.
• Detailed Reporting: Pentest reports provide in-depth insights into identified vulnerabilities and actionable recommendations to mitigate security risks.

Importance of Security Testing

Both bug bounty programs and penetration testing are crucial components of a comprehensive security strategy. They help organizations proactively identify and address vulnerabilities before malicious actors can exploit them, thereby reducing the risk of a data breach. By conducting security testing, organizations can enhance their overall security posture and build trust with their customers and stakeholders.

Understanding the Differences

\

Approach and Methodology

Bug bounty programs rely on the collective expertise of a global community of researchers, leveraging their diverse approaches and methodologies to uncover vulnerabilities. In contrast, penetration testing follows a structured methodology and best practices, often tailored to the specific needs and requirements of the organization.

Scope and Coverage

Bug bounty programs offer a broader scope, allowing researchers to test various systems and applications using a wide range of techniques. However, the scope of a penetration test can be customized to focus on specific areas of concern within an organization’s IT infrastructure. (Say like test only network devices, mobile applications, biometric devices, etc.)

Cost and Resource Allocation

Bug bounty programs operate on a pay-for-results model, where organizations only pay for valid vulnerabilities identified. On the other hand, penetration testing typically involves upfront costs, time-bound, and resource allocation for engaging a specialized security testing team or service provider. 

Scalability

The vulnerability reward program (VRPs) enables organizations to quickly initiate large-scale security testing for their internet-facing applications with limited resources. In contrast, penetration testing requires a substantial team, time, and knowledgeable resources to establish a trusted platform at scale.

Benefits of Bug Bounty

\

Diverse Skill Set

Bug bounty programs enable organizations to harness the diverse skill sets and perspectives of a global community of security researchers, providing a wide range of expertise in identifying vulnerabilities.

Continuous Testing

Bug bounty programs facilitate ongoing security testing, allowing organizations to identify and address vulnerabilities as new threats emerge continuously.

The moment when a zero-day vulnerability is first known to the community, the bounty hunters would be the first to try it out on organization systems or applications they were working on and raise the security flaw immediately within a few hours. This trend can generally spotted where their incentives are generally high.

Cost-Effective

Bug bounty programs offer a cost-effective approach to security testing, as organizations only pay for valid and unique vulnerabilities identified by researchers.

Researchers Verification

Some organizations that host bounty programs under the managed Bug Bounty platforms even request to verify the details of the security researchers before allowing them into the bug bounty program. This is an additional measure taken care of by the platforms themselves and helps to build trust.

Benefits of Pentest

\

Comprehensive Testing

Penetration testing provides a comprehensive evaluation of an organization’s security posture, identifying vulnerabilities across different systems and applications.

Generally, penetration testing is carried out either by the organization’s internal security team or by the external service provider to secure the business’s critical assets from external attackers.

When an internal team performs pen-testing, they might have access to the application architecture diagrams, documentation, development team support, and source code to provide extensive coverage.

Every possibility of security risk identified is documented, from low severity to high-severity issues in the applications or in network-connected devices. Based on risk assessment, impactful security vulnerabilities are addressed as a priority.

Controlled Environment

Pentests are conducted in a controlled environment, allowing organizations to manage the testing process and minimize potential disruptions to their operations.

In some cases, penetration testing is performed on non-production environments to minimize the impact on customers, which would be an exact replica of what would be going into production.

All the security assessments are carried out in stages and segregated into specific groups like network security, web security, mobile security, etc.

Detailed Reporting

Pentest reports offer detailed insights into identified vulnerabilities, along with actionable recommendations to strengthen the organization’s security defenses.

Business stakeholders review and direct the teams to take action to minimize the security risks, ranging from high-impact to low-impact business risks. Also, monitor the security health of their organization.

Overall, the organization’s security posture will be known with this approach.

Compliances and Best Practices

Penetration testing is also essential for meeting industry regulations, best practices, and standards. Based on the data criticality, it must be carried out at regular intervals.

Drawbacks of Bug Bounty

\

Limited Control

Organizations have limited control over the testing process in bug bounty programs, as researchers operate independently and may or may not adhere to specific testing guidelines.

In Bug bounty programs, even though organizations define a detailed scope of requirements of what is allowed and what is not, like using automated tools or looking out for specific categories of vulnerabilities as part of security testing, it depends on individual security researchers.

Bug bounty hunters are even banned or removed from the program in case of deviations from the given scope.

Public Disclosure of Vulnerabilities

Poorly managed Bug bounty programs may lead to public disclosure of vulnerabilities, potentially impacting an organization’s reputation.

In bug bounty hunting, a researcher must report a vulnerability and has to wait for a duration, say 60-90 days, for acknowledgment. Upon not receiving any communication from the organization for the given time frame, a researcher might disclose the bug publicly. This generally happens only in the case of an ineffective program.

Variable Results

The effectiveness of bug bounty programs can vary, as the identification of vulnerabilities depends on the skills and motivations of participating researchers.

The participating researchers are from a wide pool of knowledge backgrounds. It can be a security researcher, a software developer interested in security, a passionate system administrator, a college student interested in bug bounties, etc.

Bug bounty hunters, in some cases, focus only on a single target, which gives them higher chances of finding a bug by carefully monitoring the changes and immediately reporting the misconfigured ones.

On the other hand, some bounty hunters only take one category of vulnerability and keep reporting it in each application whenever they find it.

All the approach varies based on the perspective of the bug bounty hunter.

Drawbacks of Pentest

\

Time-Consuming

Penetration testing can be time-consuming, especially for comprehensive assessments that cover multiple systems and applications within an organization’s IT infrastructure.

It requires multiple parties to be involved, allocating resources, and shorter time intervals might be provided when in a hurry for production releases.

Limited Scope

The scope of a penetration test may be limited based on the specific areas of concern identified by the organization, potentially overlooking vulnerabilities in other areas.

Higher Cost

Engaging in penetration testing typically involves higher upfront costs and resource allocation compared to bug bounty programs.

Making an Informed Decision

\

Assess Your Security Needs

Organizations should assess their specific security needs by considering factors such as the complexity of their IT infrastructure, the sensitivity of their data being maintained, and the potential impact of security vulnerabilities.

Considering Budget and Resources

Budgetary constraints and the availability of a security skillset play a significant role in determining whether bug bounty programs or penetration testing is a more viable security testing solution for an organization.

Evaluating Long-Term Goals

Organizations should consider their long-term security goals and the level of control they require over the security testing process when choosing between bug bounty programs and penetration testing.

For Bug Bounty Hunters

Whether you want to learn Bug Bounty or Penetration testing, penetration testing is much rewarded for building a professional career. If you would like to do some side hustle and earn some extra bucks, Bug Bounty might be the best choice. Rarely, a few hackers built a career from Bug Bounty, but it requires patience and time and has a very steep learning curve.

Conclusion

In summary, bug bounty programs and penetration tests each offer unique benefits and drawbacks, catering to different security needs.

Organizations, by carefully evaluating the differences and considering specific requirements like the scope of testing, the level of control required, and the budgetary constraints, determine the most suitable approach for addressing security vulnerabilities, which can help to enhance your security posture effectively.

For Bug Bounty hunters, consider your skill set and the time available to choose the one that suits you best. Both required similar skill sets, but the approaches and efforts vary.

In the ever-evolving cybersecurity landscape, one must adapt to changing security testing strategies to mitigate risks and protect digital assets effectively. Whether through bug bounty programs, penetration testing, or a combination of both, proactive security testing is essential for safeguarding against potential threats and maintaining a robust security posture.

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

XSS Challenge Walkthrough

Once your Kurukshetra XSS lab environment is up and running, Visit http://localhost:8066 and navigate to “XSS Challenge 14“.

The above input field labeled “Try your XSS payload here?” is displayed.

Key info is in the classic XSS payload, which has been used throughout while testing for XSS, and click on the “Submit” button.

XSS Payload

Output:

The application doesn’t display any info on the page. Right-click and select “View page source” to analyze how the appended payload got reflected in the HTML response.

Viewing HTML Source

In the above output, the javascript “alert()” function is missing.

Let’s go ahead and give it a try with an HTML body tag-based XSS payload to confirm if the “alert()” function is being filtered in the script tag itself or from all inputs.

XSS Payload 2

HTML Source Output:

From the above output, it can be confirmed that the JavaScript “alert()” is being filtered out in all the inputs given.

In the current scenario, the JavaScript function “alert()” is commonly used by attackers to execute arbitrary code. This type of blacklisting approach used to prevent XSS attacks involves identifying and blocking specific strings or functions that could be used by attackers to inject malicious code into a web application.

The major drawback of this approach is the developers need to update the impactful functions/commands to the blacklist continuously.

By removing or disabling these functions, web developers hope to prevent attackers from exploiting XSS vulnerabilities in their applications. However, this approach is often ineffective, as attackers can simply use alternative methods to execute their payloads, such as using “confirm()”, “prompt()”, “console.log()” or constructing their own functions.

Demo – XSS Challenge 14

For the following demo, we will be using the JavaScript “confirm()” function.

The “confirm()” function in JavaScript is a built-in method that displays a dialog box with a message and two buttons: “OK” and “Cancel”. It is often used to prompt the user for confirmation before performing a potentially destructive action, such as deleting data or navigating away from a page.

I will go ahead and replace the “alert()” function with the “confirm()” function and update our XSS payload accordingly.

Confirm XSS Payload

Now, let’s go ahead and input the above XSS payload in the “XSS Challenge 14” page.

Immediately after clicking on the “Submit” button, a pop-up message will be displayed, as shown below.

The above screenshot demonstrates the javascript “confirm()” prompt. Which looks very similar to the “alert()” dialog box with the added button “Cancel” as a difference.

This also confirms that the application is vulnerable to cross-site scripting vulnerability.

To verify further, click on the “OK” button in the dialog prompt, right-click, and select “View page source”.

Viewing HTML Source

Observe the injected XSS payload is reflected in the HTML source and executed perfectly.

By this, we can confirm that XSS challenge 14 is successfully solved.

Summary

In this article, we demonstrated one of the impacts of the blacklisting approach where the “confirm()” or other alternative javascript functions can be abused by attackers in XSS attacks, as they can use it to trick users into executing arbitrary code or disclosing sensitive information.

To prevent XSS vulnerabilities in web applications, it’s important to validate and sanitize all user input and implement appropriate content security policies.

Congratulations to all our readers who completed the learning XSS with the Kurukshetra series! I hope that you enjoyed our vulnerability series and learned a lot in the process. If you’d like to learn more or have any feedback or suggestions, please don’t hesitate to reach out. We’d love to hear from you!

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

XSS Challenge Walkthrough

Once your Kurukshetra XSS lab environment is up and running, Visit http://localhost:8066 and navigate to “XSS Challenge 13”.

An input field labeled “create a link?” is displayed.

1. In the above input field, give a URL (say “http://localhost:8066/ch13.php“) to which you want the application to create a link for us.

2. Click on the “Submit” button.

Observe the application generated an HTML link for the given URL displayed above.

From the above application, we can understand that with any given input text, the application generates a clickable HTML link.

Feel free to try out all the XSS techniques learned so far. You should be able to solve this challenge right away. 😃

XSS in Anchor Tag

Going ahead, we will cover how the HTML anchor tag can be used to craft a customized XSS payload.

From the above HTML link generated, right-click and select “View page source“, then search for the appended text in the HTML response.

From the above screenshot, we can see the given input text is placed between the “href” in an anchor tag, and the same text is placed again as the name of the anchor tag.

Output:

I will go ahead and create a crafted XSS payload which is generally attackers used to trick victims into a trap.

XSS Anchor Payload

Breaking down the above XSS payload in detail:

1. Leaving the “href” tag empty without a link and closing it with another pair of double quotes to ensure HTML syntax is maintained.
2. The “onclick” is an HTML5 attribute used within HTML tags that specifies a JavaScript function to be executed when the user clicks on the element. In this case, the function being executed is “alert(‘xss')“, which displays the alert dialog with the message “xss“.
3. “Click for XSS POC” a text message will be displayed for the anchor tag.
4. Closing the HTML anchor tag with “</a>“.
5. The start of the HTML comment with “<!–” then comments out all the code after this is parsed as text with no special meaning.

Overall the above XSS payload creates a clickable element that, when clicked, will execute a JavaScript alert dialog with the message “xss“.

XSS Demo

Go ahead and give it a try with the above-crafted XSS payload.

In the above screenshot, key in the XSS payload and click on the “Submit” button.

From the given payload, the application generates an HTML link and displays it, as shown above. Now click on the “Click for XSS POC“.

Immediately, a pop-up box is loaded, and a message named “xss” is displayed. Thus, we have solved XSS challenge 13.

Note: One of the many techniques is covered here. The XSS payload can be crated in multiple other ways as well.

Lastly, right-click and select “View page source” to understand how it’s reflected back in the HTML response.

From the source code, the XSS payload is appended inside the anchor tag, and all the HTML code is commented out after the anchor tag.

As mentioned above, the XSS payload allows the attacker to execute arbitrary JavaScript code on the victim’s browser when the element is clicked. This can result in the theft of sensitive information, such as session cookies or user credentials, or the takeover of the victim’s account.

By this, we have successfully solved the XSS challenge 13.

Summary

The following article demonstrates how the customized XSS payload allows an attacker to execute arbitrary JavaScript code.

The code also includes an HTML comment “<!--”, an attempt to prevent the malicious code from being easily detected. This technique is known as “comment hiding”, and attackers often use it to obfuscate their payloads and evade detection.

To prevent XSS attacks, input validation and output encoding should be applied, and a Content Security Policy can also be used to mitigate the risk of the above XSS vulnerability.

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

‌XSS Challenge Walk-Through

Once your Kurukshetra XSS lab environment is up and running, Visit http://localhost:8066 and navigate to “XSS Challenge 12“.

1. Click on “XSS Challenge 12” on the left side menu.
2. Input the XSS CSP bypass payload which was used in the previous demonstration and will observe how the application behaves.

1. Click on the “Submit” button.

Application Output:

1. The application loads normally and displays a text message, “Your XSS Payload”, without any pop-ups.

2. Right-click and select “View page source“, then search for the injected XSS payload. The HTML response code will be displayed below.

1. At the bottom of the HTML response, the XSS payload was injected as provided and also aligned rightly with the HTML syntax. But the javascript code wasn’t executed.

2. You might have guessed right! The application’s Content Security Policy might be blocking our payload. Let’s go ahead and review the current CSP policy set.

Analyzing the CSP policy

On the following XSS challenge page, Press the “F12” button on your keyboard and a new browser debugger window will be launched.

In browser debugger mode navigate to “Console” and observe the CSP violation messages will be displayed as shown below.

As expected, the browser blocks script code due to CSP violations and prevents execution.

Will try to understand the application CSP policies, In debugger mode switch to “Network” and reload the challenge page.

Select the “ch12.php” page and scroll to the “Response Headers” section. Observe, the Content-Security-Policy header which was set by the application server.

Understanding the CSP Policy Implemented

Breaking down the CSP rules:

1. “script-src“: This directive restricts the sources from which scripts can be loaded. In our case, it allows scripts to be loaded only from the same origin as the page (i.e. “self“),
2. Secondly, the scripts can be loaded from https://facebook.com, https://google.com, any HTTPS sources (“https“), the “data” scheme, and any source (*).
3. child-src: This directive restricts the nested frame contents from loading.
4. report-uri: This directive specifies a URL to which policy violation reports should be sent.

Overall, CSP policy allows scripts to be loaded only from trusted sources, including the same origin as the page and specific external sources like Facebook, Google, and other HTTPS domains.

Why is “data:” directive-based XSS not working?

Content-Security-Policy: script-src 'self' https://facebook.com https://google.com https: data *; child-src 'none'; report-uri /Report-parsing-url;

This is because the CSP policy explicitly disallows scripts to be loaded from the “data:” scheme, except for the page’s own origin (i.e., ‘self‘ same domain).

In the script-src directive, the “data” scheme is listed as a source along with the wildcard *. However, the wildcard “*” here does not override the previous ‘self’ directive, meaning that scripts can only be loaded from the page’s own origin via the “data:” scheme but not from the user-injected external scripts.

Therefore, the “data:” scheme tries to load an external script, which was blocked by the CSP policy, and the “alert(‘XSS')” payload doesn’t execute.

Is it possible to bypass the limitations set?

Well, the more you get familiar with the technologies, the more options you will be able to find.

Closely observe there is another directive named “https:” in script-src. It is configured in such a way that scripts can be loaded from any of the HTTPS sources.

Content-Security-Policy: script-src 'self' https://facebook.com https://google.com https: data *; child-src 'none'; report-uri /Report-parsing-url;

Yes, one option is setting up your own HTTPS site and pushing an XSS javascript file onto the server and using it for testing purposes.

It’s a long process, but I will be using the publicly available one for the proof of concept.

Security researchers from Cure53 have provided the needed resources that can be directly used for security assessment. The reference link can be found below:

https://github.com/cure53/H5SC

Demo – CSP Bypass

Let’s use the remote “https” javascript payload taken from the H5SC report, the payload URL is given below.

https://html5sec.org/test.js

Javascript source code in the “test.js” file contains only the alert() function as given below. If worked, will display a pop-up message “1“.

alert(1)

Will append the above URL to the script code so we can key it into the input field.

Visit the XSS Challenge 12, paste the above payload in the input form field, and click on the “Submit” button.

Immediately observe a pop-up box will be loaded with the message displaying “1”. By this we can confirm we have successfully exploited the misconfigured CSP.

In all XSS payloads, we used “alert(‘XSS')“, an alert() function to display text message ‘xss‘ so far, in the above case, the same alert function was used to display the numeric digit in a pop-up window.

Click “OK“, then Right-click and select “View page source” to verify the injected payload.

Post review can confirm that the XSS payload reflected as given and executed successfully.

By this, I can say that XSS Challenge 12 has been successfully solved. Yayy!!! 🎉.

Use of the “https” sources from any domain can be problematic from a security perspective, as it allows arbitrary javascript code to be loaded from any external source and executed directly on the page, which is generally abused by attackers to perform cross-site scripting (XSS) attacks.

\

Summary

A Content Security Policy (CSP) can prevent cross-site scripting (XSS) attacks by limiting the sources from which scripts can be loaded.

However, if a CSP policy is misconfigured, it can potentially allow XSS attacks to occur. In the above case, allowing the javascript code to load from any remote “https” resources can enable attackers to inject malicious scripts directly into a web page, potentially leading to XSS attacks.

Therefore, a well-configured CSP policy can block all XSS attacks, and it is important to ensure that CSP policies are correctly configured and free from insecure directives.

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

‌XSS Challenge Walk-Through

Once your Kurukshetra XSS lab environment is up and running, Visit http://localhost:8066 and navigate to “XSS Challenge 11“.

1. Click and select the XSS Challenge 11 from the Kurukshetra app.
2. Fill out our classic XSS payload in the given input field.
3. Click on the “Submit” button.

Output:

1. The application loads the page as usual and displays a text message, “Your XSS Payload” without any pop-ups.

2. Right-click and select “View page source“, then search for the injected XSS payload. The HTML response code will be displayed below.

1. At the bottom of the HTML response, the payload was injected as provided and also aligned rightly with the HTML syntax. But our javascript didn’t execute.

What might be happening in the background?

In the above screenshot, if the HTML output encoding is used, then the output must be displayed as “<” or “>” etc. Doesn’t look so. Also, if slash-escape is being used, then the prefix slashes must be displayed. Even that is not present.

Seems like our XSS payload is injected rightly but unable to execute. A possible guess is there is some sort of other XSS defense in place.

The web application might have enabled the Content Security Policy or other XSS protection headers. Let’s verify and understand what’s happening in the background.

On the following XSS challenge page, Press the “F12” button on your keyboard and a new browser debugger window will be launched.

In browser debugger mode navigate to “Console” and observe the CSP violation messages will be displayed as shown below.

Web Browser clearly indicates some script code tried to execute but it’s not compliant with the CSP policy set. Therefore it was blocked by the browser from executing.

In debugger mode, switch to “Network” and reload the challenge page.

Select the “ch11.php” page and observe on the right side in “Response Headers” the Content-Security-Policy header, which was set by the web application.

Understanding the CSP implementation

Breaking down the CSP policy defined by the web application

1. script-src: specifies the sources from which scripts can be loaded.

• https://facebook.com: allows scripts to be loaded from the domain facebook.com.
• https://google.com: allows scripts to be loaded from the domain google.com.
• unsafe-eval: This allows the eval() javascript function and the Function() constructor to execute dynamically created script code.
• “data:”: allows the execution of inline scripts (one which is directly embedded in the HTML) with data URIs.
• “http://*”: Wildcard “*” means allows scripts to be loaded from any HTTP sources (poses a security risk).

2. child-src: specifies the sources from which nested browsing contexts (such as iframes or embedded objects) can be loaded. In this case, ’none’ specifies that no sources are allowed.

3. report-uri: specifies the URL where a browser should send violation reports if the policy is breached.

Overall, this CSP allows scripts to be loaded from trusted domains (facebook.com and google.com), as well as inline scripts and HTTP sources (which are generally not recommended due to security risks). It also allows the use of eval() and Function(), which can be used to exploit XSS attacks. Additionally, it prohibits the loading of nested browsing contexts and specifies a URL to which violation reports should be sent.

The above CSP policy clearly has some limitations and is not foolproof. That said, “data:” provided an entryway for us to try creating XSS inline scripts or load the XSS script code from any of the HTTP domains, tricking the application by loading from Google, etc.

Exploiting XSS using Inline scripts

(i.e., using data directive)

Let’s go ahead and find a way to bypass the misconfigured CSP defenses. For the following demonstrations, we will be using the script-src’s “data:” attribute to craft an XSS payload.

From the documentation script source “data:” can be used for inserting inline scripts directly into HTML documents.

The “data:” URI scheme allows data to be embedded directly in a URL or document, using a specific syntax that includes the “data:” prefix followed by the MIME type of the data, and the data itself.

Below is an XSS inline script using the “data:” URI scheme, which can be included directly, with the MIME type set to “text/javascript” and an “alert(‘xss’)” data.

Above code will pop up with an “XSS” message when the javascript code is loaded and executed directly on the page.

Visit the “XSS challenge 11” page.

Enter the XSS inline script code in the input field and click on the “Submit” button.

Output:

Immediately, we can see a pop-up message displayed on the web page. By this, we can confirm that we have successfully exploited the XSS vulnerability. :D

To further confirm, click on the “OK” message, then right-click and select “View page source”. Search for the injected XSS inline script code.

HTML Page Source:

Observe this time, our injected script code is reflected back as given without any output being filtered.

The execution script code confirms we have successfully solved the XSS challenge 11. Yayy!!!.

Use of the “data:” URI scheme for inline scripts can be problematic from a security perspective, as it allows arbitrary code to be executed directly on the page, which is generally abused by attackers to perform cross-site scripting (XSS) attacks.

Summary

A Content Security Policy (CSP) policy restricts the types of content that can be loaded by a web page. When implemented correctly, a CSP can prevent cross-site scripting (XSS) attacks by limiting the sources from which scripts can be loaded.

However, if a CSP policy is misconfigured or contains errors, it can potentially allow XSS attacks to occur. For example, if a policy includes insecure sources, such as “unsafe-inline” or “data:”, it can enable attackers to inject malicious scripts directly into a web page, potentially leading to XSS attacks.

Therefore, a well-configured CSP policy can block all XSS attacks, and it is important to ensure that CSP policies are correctly configured and free from insecure directives.

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

‌XSS Challenge

You reached “XSS Challenge 10”. Great to see your consistent progress. In the past article, we covered how the XSS vulnerability does not always need to be exploited using the same parameter. XSS can also be looked at in other parameters, which might depend on the param, or it can also be an appending parameter.

Let’s get started with XSS Challenge 10. Visit: http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 10“.

1. Click and select the XSS Challenge 10 from the Kurukshetra app.
2. Will fill out some random string saying “ABC” in the input field provided.
3. Click on the “Submit” button.

Output:

Feel free to experiment with your XSS ideas before going ahead with the next steps.

Hope you have partially or successfully exploited it.

Viewing the Page Source

In the above screenshot, I have keyed the text “ABC” in the input field. Let’s verify how the text is being reflected back in the HTTP response code.

To do that, “Right-click” and select “View Page Source”, then search for the inserted string “ABC”.

Injected text is being reflected back at the bottom of the page, and this time, it’s inserted between the HTML div tags with double quotes appended.

Remember from the previous lessons, we can keep trying out the different XSS payloads, but at the same time need to gather the list of allowed characters as well which can help in crafting an XSS payload.

Going ahead, will be trying out all the payloads and narrow down to the allowed characters.

Payload 1 – Simple XSS

Browser Output:

Page Source – Output:

Closely observing the closing </script>, a “\” backslash is appended and turned the closing script to <\/script>. This breaks the HTML syntax, as it’s expecting the closing script tag.

About Slash-Escape

The backslash escape is a technique used to prevent special characters from being interpreted as code in web applications. Currently, this application is using the same to block XSS attacks.

The above technique is good when used in combination with multiple XSS prevention techniques. (i.e., Defense in Depth).

Also, note that in the above case, the backslash “\” is only being appended to the slash in the closing script tag, not for any other special characters, which is an indication of poor XSS mitigation.

TIP – 10 Try HTML tags that work without closing tags

Yes, as mentioned in the heading. Not all HTML tags need to have a compulsory closing tag, and there are some HTML tags that work even if the closing tag is not provided. (say <IMG>, <SVG> etc.)

This time for a change will go ahead and try the HTML image tag payload than using the same routine one.

XSS Payload – HTML Image Tag

Breaking down the above payload into detailed steps.

• “<img>” is an HTML tag used for embedding images on a web page.
• “src” is an attribute of the HTML “<img>” tag that specifies the URL of the image file from where it needs to be loaded.
• “x” is a random value assigned to the “src” attribute forcibly. As there is no image file named “x“, the browser will fail to display/load the image.
• “onerror” is another attribute of the “<img>” tag that is called if an error occurs while loading the image.
• “alert(‘XSS')” is a JavaScript function that displays an alert dialog box with the message “XSS”.

Putting it all together, when the web page containing this XSS payload is loaded in the browser, the browser will try to load the image file “x”. As the image file cannot be loaded due to non-existent, the onerror attribute is triggered and the JavaScript code alert(‘XSS’) is executed, which displays a pop-up message “XSS”.

Demo – HTML Image Tag XSS Payload I will go ahead and insert the “<img>” tag-based payload and verify how the application behaves.

Output:

Wow!! 🎉 an XSS pop-up message. This confirms that our payload worked.

Lastly, let us go ahead and further verify by viewing the page source. Click “OK”,

Right-click on the page and select “View Page Source“. Then, search for the injected string.

HTML Response

Observe, the payload is rightly aligned between the div tag and backslash and is no longer breaking the HTML syntax. By this, we have successfully solved the XSS challenge 10.

Summary

The following article covered one of the poorly implemented XSS fixes of escaping using backslash for special characters. That, too, only escapes the closing script tag. These limitations can be bypassed using HTML image tags and other ways. Therefore a “Defense-in-Depth” approach is needed to mitigate XSS vulnerability at multiple layers.

In today’s article, let’s check out how the XSS can also be exploited in hidden input parameter fields.

Before getting started, ensure your Kurukshetra lab is up and running. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

The previous article covered how the limited character set can be leveraged to exploit the XSS vulnerability and why the single defense mechanism might not fully mitigate XSS vulnerability.

Practicals

Visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 9“.

The above page looks similar to the challenges we solved earlier.

Take some time and give it a try with all the XSS skills acquired so far before going any further.

As you guessed, I will go ahead and try out the classic XSS payload to verify how the application responds.

Payload Try 1: Classic

Output:

Input the XSS payload and click on the “Submit” button. Immediately, the application echoes out the output as given, and there are no pop-up messages this time.

This confirms that our payload didn’t work. Right-click and select “View page source” to understand how our payload is being reflected back in the HTML response.

HTML Page Source:

Referring to the above screenshot, an HTML input tag named “xss” accepts the value and echoes out at the bottom of the code after encoding the special chars.

You might be thinking from the previous article that we used the built-in “HTML attributes” to bypass the encoding and execute the XSS payload. The same logic can be applied here.

A big No. Why?

Challenge 8 – HTML Output:

Challenge 9 – HTML Output:

The major difference between XSS Challenge 8 and Challenge 9 is that in Challenge 8, the encoded output was injected inside the HTML input tag, while in Challenge 9, the encoded output is displayed outside of form HTML tags.

As shown in the above challenge 9 screenshots, even though the HTML attributes can be injected, as they fall outside the HTML tags, the web browser would just consider it as text without any special flags.

Therefore, the XSS payload will not work here.

TIP – 9 Try other params or check for appending values

Yes, the XSS need not always need to be exploited in the same param value location, it could be checked on the other supporting param which may use the same value for processing. Also, it can be located in param values where input values are appended or depended on.

Challenge 9 – HTML source Output

Paying a bit more attention to our Challenge 9 HTML response, we can see there is another HTML input tag used of type “hidden”.

In HTML, the hidden input type stores pieces of user data without displaying it to the user on the frontend. Web browsers generally hide it, and you can find this data by viewing page sources or by using intercepting proxies like BurpSuite or OWASP ZAP.

Let’s go ahead and try the XSS payloads in the hidden fields.

It can be done in multiple ways, as covered in previous articles, such as using a browser debugger or using intercepting proxies. I will be using the BurpSuite proxy for usability.

Execution Steps

1. Configure and Launch the Burpsuite tool.
2. Navigate to the “XSS Challenge 9” page.
3. Enable the BurpSuite interception proxy to intercept the request before it is sent to the server. To do that, Navigate to BurpSuite “Proxy” -> “Intercept” -> Toggle the “Intercept is off” button to enable “Intercept on”.
4. On the Challenge 9 page, key in the random input value(say “Test XSS”) and click on the “submit” button.
5. The intercepted request will be displayed as shown below:

1. Observe that in line 22, the input param and its values are being passed in the request body section.

2. Replace the “hidden” param value from “Is that it” with classic XSS payload.

The modified request will be displayed below.

1. Toggle off the “Intercept is on” button to disable the request interceptions for now and forward the modified request to the server. Then, switch back to the web browser.

2. Immediately observe an XSS pop-up message, which will be displayed as shown below. then click on the “OK” button.

1. Wow!! It worked out, and we were able to successfully exploit XSS challenge 9. 😄

Lastly, always verify the HTML response code. Right-click and select “View page source” to verify how the injected XSS payload is appended.

I can confirm that the injected XSS payload in the hidden parameter value field has been passed to the server and reflected back in the response without any encodings this time.

Hence, our payload was executed. ☺️

Summary

In this article, we’ve seen how other parameters can be utilized to exploit XSS – it doesn’t always have to be done within the same param field.

Before we start, ensure the lab is up and running. If you have not set up your lab yet. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

Practicals

Hope by now you are familiar with what an XSS is and how it can be identified. In this article, you will be learning about how to exploit XSS when limited characters are allowed.

Post setting up the lab visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 8”.

From the above screenshot, I can see that the application is requesting the input value in the “Try Your XSS payload?” field.

Feel free to try and experiment with different payloads.

Initially, I will go ahead and try out our classic XSS payload, which has been used throughout our series.

Payload Try 1: Classic

Output:

After keying in the payload value and clicking on the “Submit” button. Looks like nothing happened.

No pop-ups and no partial or filtered messages. Interesting!

Let’s go ahead and view the HTML source code received from the server to understand what is happening in the background.

Right-click and select “View page source”, then search for the injected payload string.

From the above screenshot, it could be understood that output encoding has been applied to injected XSS payload which prevents execution of the script tag.

Try out and verify all the XSS payloads which have been discussed throughout the series. Using IMG tag XSS, SVG tag-based XSS, etc.

Tip 8 - Use allowed characters to build XSS payload

As the heading says, you can keep on trying out any number of HTML tags and verify which XSS payload works. Or another better option could be to find out the list of allowed characters with multiple trials and errors and craft one using the allowed list of characters.

Identifying Allowed Characters

Using previous XSS payload output can confirm the javascript alert() function is allowed, next single quotes “’” are allowed, “/” slash is allowed, and lastly alphabets are allowed too.

Now need to find out, how the allowed list of characters can be used and make the XSS payload work.

Remember the XSS payload used in “Challenge 4”, Using HTML5 Attribute.

In the above XSS payload, can see that most of the characters are allowed, but we haven’t verified double quotes “”.

Quickly will go ahead and verify if the double quotes are allowed in the input field. By injecting and viewing the page source code.

Output 2:

Now, can confirm that double quotes are also allowed as injected without any encoding or escaping. Nice!

Let’s understand the XSS payload before trying it out.

Our motto is to rightly align the XSS payload in HTML response code and make it executable.

All the injected payload characters are inserted within the HTML input tag within the value field.

If the input is keyed in like onmouseover=alert(‘xss’) without quotes, it would be treated as text, and all the HTML attributes will not be of much help here. For the same reason, we use the extra quotes to properly align inside the input value field.

1. A double quote for closing the value section
2. onmouseover is one of the HTML attributes that can be used with HTML tags. The moment the mouse hovers over the code, the given javascript alert() function gets triggered.
3. Another double quote to make sure the remaining double quote of the value field is aligned with HTML syntax.

Enter the above-improvised payload in the input field and click on the “Submit” button.

Output 3:

For a moment, things seemed like nothing had happened, and the application behaved normally as expected. As seen before.

Hover over your mouse onto the input field and observe, immediately a pop-up message is prompted as shown below.

Waah!! 🎉 Our XSS payload worked. Let’s verify the HTML response code to confirm how the XSS payload is aligned further.

Right-click on the “View page source” and search for the injected XSS payload string.

The given payload got rightly aligned and only the allowed list of characters and HTML attributes have been used to exploit it.

We have successfully solved the XSS challenge 8.

Summary

This post demonstrates how generally output encoding is used to prevent XSS, but that itself is not enough to prevent the XSS vulnerability. The input HTML attributes and allowed characters can be carefully used to craft a working payload. To prevent the XSS vulnerability a Defense-In-Depth approach needs to be leveraged. Like performing output encoding, sanitizing, using CSP, etc. Which would be covered later.

Keep learning! 😃

Before we start, ensure the lab is up and running, If you have not set up your lab yet. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

Recap

The previous article covered reflected cross-site scripting scenarios where poor input validation checks can be exploited further.

Also, it demonstrated the impact of missing input validation checks on the server side. Therefore the input validations must be implemented well on both the client & server sides.

Practicals

Post setting up the lab visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 7”.

Coming to XSS Challenge 7, an input field is given to key in the text and a drop-down menu option needs to be selected before clicking on the “Submit” button.

Will try out all the things techniques learned so far about identifying the XSS vulnerability.

Payload Try 1: Classic

Output:

Using our classic payload, select the default option in the drop-down menu “India”, then click on the “Submit” button.

Immediately, observe that the payload keyed in is displayed as it is. Right-click and select “View page source” to understand how the payload is being embedded in the HTML response.

Scrolling to the bottom of the page, I can see that our tags like ‘<’, ‘>’ etc.. have been replaced. This changes the meaning of the HTML format, and the browser considers it as text and displays it back without executing it as a script.

1. HTML Output Encoding

   The above output that we are seeing is called HTML output encoding.

   Output encoding is one of the mitigation techniques used to take user-controlled data and safely display it without interpreting it as code and considering it as text.

   Below is an example XSS payload.

   <script>alert(document.domain);</script>
   

   HTML-encoded text of the XSS payload will be displayed below.

   <script>alert(document.domain);</script>
   

   • “<” changed to “&lt;”
   • “>” changed to “&gt;”

   As the browser parses HTML, JavaScript, CSS, and URL differently. Each must be encoded depending on the requirements.

   URL, HTML, JavaScript, and CSS can be encoded.

   The input text field in the application seems to be handled properly, but we need to find another way to exploit it.

   ---

   

   Tip 7 - Try exploring other param values

   XSS need not be present all the time in the input text fields, it can be found in other parameters as well which are parsed and used by the server.

   ---

   

2. Trying XSS in the “location” param

   I will be using the “BurpSuite” proxy tool going ahead with the demo. Please make sure your browser is preconfigured with the BurpSuite and working as expected.

   Visit the Challenge 7 page.

   Enable the BurpSuite interception proxy to intercept the request before it is sent to the server. To do that, Navigate to BurpSuite “Proxy” -> “Intercept” -> Toggle the “Intercept is off” button.

   

   Fill up the input field value with “Test XSS” and then click on the “Submit” button.

   

   Now in the “BurpSuite” proxy tool, observe the request being transmitted to the server, is intercepted, and displayed as shown below.

   

   Observe at the bottom of the request the “xss”, “location” and “submit” params are being passed to the server.

   Remember, in the previous article Challenge 6, we sent the modified XSS payload to the server.

   In a similar way, this time in the “location” param value append our classic XSS payload, which will be displayed as shown below.

   

   Next, toggle off the “Intercept is on” button to disable the request interception for now. Immediately switch back to the web browser.

   

   Immediately observe that an XSS pop-up message will be displayed, as shown below.

   

   YAY!! 🎉 by this, we can confirm the application is still vulnerable to the cross-site scripting vulnerability.

   Click the “OK” button to continue, then right-click and select “View page source” to very our payload injection. Search for the payload inserted.

   

   You can find the inserted payload at the bottom of the page. This time, you can see that our payload is displayed as given without any output encoding.

   By this, we have successfully exploited the XSS challenge 7.

   ---

   

Summary

The key takeaway from this article is XSS need not necessarily be exploited from the user input form fields, the XSS vulnerability can be tested in any param header and value fields that are parsed by the server.

Keep learning! 😃

Before we start, ensure the lab is up and running. If you have not set up your lab yet. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

Practicals

Post setting up the lab visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 6”.

I hope by now you are familiar with what an XSS is and how it can be exploited. In this article, we shall learn more about identifying XSS vulnerabilities.

Without much waiting, let’s try our classic XSS payload on “Challenge 6” and understand what the result we are getting.

Payload Try 1: Classic

Output:

The output seems to be something familiar. We have seen this type of output earlier as well.

Yes, we have seen this type of output when learning about the reflected cross-site scripting vulnerability in Challenge 3. We. Almost the same, with a slight change.

Let’s explore it.

Understanding Application Behaviour

Below is the output that we received when trying to use a classic XSS payload.

Right-click and select “View page source” to view the HTML source code. I search and scroll down through the HTML code to understand what is happening with our input field. You will be able to find the code snippet as shown below.

The HTML input tag seems very similar as seen in previous challenges.

Taking a closer look, whenever we click on the “submit” button, the HTML form is running a “filter()” javascript function.

JavaScript is used for adding dynamic capabilities to the page making it user-friendly.

In the same HTML code, will search for the javascript code.

Scrolling through the top of the page, I can see a javascript file named “ch06.js” has been included. Clicking on the file, the javascript code opens, as shown below.

We found the “filter()” function javascript code. A blacklisting approach of input filtering is being used.

You can see the script, svg, and img HTML tags being stripped out on the client side by the javascript filter() function.

The above code is an example that demonstrates that the client-side validation check is in place. Remember from the previous article

Input validation checks need to be applied on both the client and the server side.

Tip 6 - Client Side validations can be bypassed

Yes, you are hearing right. Every piece of instruction sent from the client side browser can be tampered with or removed or new data can also be added.

One way is through using browser addons like i.e. Tamper Data for Chrome etc. Available for firefox as well.

Another way is using the interceptor proxy tools like BurpSuite or OWASP ZAP. Once configured with the web browser, they can help to view/modify every request before it is sent to the server.

In our demonstrations going ahead, I will be using the “BurpSuite Community” edition. Please refer to the tool documentation which can help you in getting started.

1. Bypassing Client Side validation

   Hope by now your web browser is configured and ready to use with the BurpSuite.

   Step 1. Navigate to “XSS Challenge 6”

   

   Step 2. Enable the BurpSuite interception proxy to intercept the request before it is sent to the server. To do that, Navigate to BurpSuite “Proxy” -> “Intercept” -> Toggle the “Intercept is off” button.

   

   Step 3. In the XSS challenge 6 page, key in with the classic XSS Payload, then click on the submit button.

   

   Step 4. Observe the intercepted request from your web browser, which will be displayed below.

   

   Don’t worry about the overwhelming information. This is the RAW format in which the web browser and server exchange HTTP messages. The underlined text indicates our input text is being sent in a URL-encoded format.

   Decoded text is nothing but the filtered input value.

   

   This explains why JavaScript validations strip out our XSS payload on the client side.

   Step 5. Replace the underlined text with our classic XSS payload, as shown below.

   

   Step 6. Toggle off the “Intercept is on” button to disable the request interceptions for now. Immediately switch back to the web browser.

   

   Step 7. Immediately observe that an XSS pop-up message will be displayed, as shown below. then click on the “OK” button to continue loading.

   

   The application load back the challenge page normally. To further confirm click on the “View Page Source” for our injected XSS payload.

   

   YAY!! 🎉 By this, we can confirm the application is still vulnerable to cross-site scripting vulnerability.

   ---

   

   The XSS payload still worked because the input field validation is only implemented on the client side using JavaScript but not on the server side.

   As there were no filters on the server side, our XSS payload passed through as an HTTP request to the server and reflected in the HTTP response as keyed-in.

   ---

   

Summary

The important lesson to take away from this article is that for the developers, the input validations need to be implemented both on the client side as well as on the server side. For security researchers, make sure to verify the validation checks are equally implemented on the server side as well.

Keep learning! 😃

Before we start, ensure the lab is up and running if you have not set up your lab yet. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

Practicals

Post setting up the lab visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 5”.

Give it a try with all the payloads we have learned so far.

I will go ahead and give it a try with our classic XSS payload.

Payload Try 1: Classic

Output:

Observe that we cannot enter any characters after “<sc”. All the characters typed after are no longer considered.

What might be happening in the background?

Let’s go ahead and view the page’s HTML source code to understand further. Type “Ctrl + u” or right-click and select “View page source”.

In the HTML source code, scroll down to the input field and you should be able to see the code similar to the one below.

For the current input field where we are trying to enter the values, the “max length is set to 3”. For the same, we are not able to enter more than 3 characters in the input field.

Can we bypass the length limitations? Possible. let’s give it a try.

Tip 5 - Client/Server Side validation bypass

In general, input validations for the applications will need to be validated both on the client side and on the server side.

In some cases, the input validations might be missing on either side.

1. Tampering Client Side validation

   In our current scenario, we surely know that the length limitations for the characters are set on the client side. (i.e. maxlength=“3” )

   There are many ways to do it, in this article we shall be using a simple technique using the browser’s inbuilt functionalities.

   Output:

   

   On the current output page, right-click on the input field and select “inspect”. (In some cases, you might need to right-click on the input field and select “inspect” twice to narrow down to the exact position of the input HTML code)

   Output from the “inspect” will be displayed below.

   

   Double click on the maxlength=“3” value field and change it to 200 or some bigger value.

   

   Observe, now the length limitations on the client side are updated and then click on cross “x” to close the browser debugger.

   Let’s go ahead and re-try out the classic XSS payload.

   

   Output:

   

   Yay!!! 🎉 we got an XSS pop-up.

   Yes, We have successfully exploited the XSS vulnerability again by tampering with client-side validation checks.

   One thing to take away from this article is all the validation checks applied on the input field need to be applied on both client side and on the server side.

   ---

   

Summary

In this article, we learned how client-side validation can be tampered with and bypassed to execute the XSS payload. Also, learned that the input validations need to be equally applied both on the client/server side.

Keep learning! 😃

Before we start, ensure the lab is up and running. If you have not set up your lab yet. Feel free to refer back to the below link.

XSS Explained - Learn Cross-Site Scripting with Examples

Practicals

After setting up the lab, visit http://localhost:8066 and ensure it’s accessible, then navigate to “XSS Challenge 4”.

Give it a try with all the payloads you have learned so far.

I will go ahead and give it a try with our classic XSS payload.

Payload Try 1: Classic

Output:

Enter the XSS payload in the input field and click on the “Submit” button.

This time, we haven’t gotten any pop-up messages indicating that our XSS payload didn’t work.

Right-click and select “View page source”, then search for the given payload to understand what exactly is happing with injected payload.

Observe, that our script code given as input, is reflected in the HTTP response and is correctly placed in between the input value quotes. Which is working as expected.

All the payload is being treated as a text value and is no longer able to control the behavior of HTML code.

Can we assume that the vulnerability is fixed? May be

Closely observe that all the characters typed in the input payload are being injected and reflected in the HTML response without much filtering or encoding.

It is worth to give a try with other possible ways of exploiting XSS before we can confirm whether it is fixed or not.

TIP - 4

The XSS payloads may not work as given all the time. We need to learn and find what allowed characters are and a working payload needs to be carefully crafted out from the allowed list of the character set.

Previous HTTP Response Screenshot:

In the above, all the given XSS payload is being placed inside the double quotes. Let’s improvise the payload by appending a double quote before the script tag and see if it can control the HTML response behavior.

Improvised Payload 1:

Enter the above payload in the input field, then click on the “Submit” button.

Browser Output:

For the immediate response, click on the “View page source” and search for the injected payload and how it’s being reflected in the HTTP response.

Interestingly, the double quote gets injected and aligns well with the HTML response code. As we can control the HTML response behavior, This gives us hint that there is a possibility to exploit reflected XSS further.

We now have most of the information to craft a working XSS payload.

The XSS payload here can be crafted in a couple of ways.

1. Trying to use the available/allowed HTML5 event attributes to execute the reflected XSS. As used in the previous article.
2. Closing the HTML input form tag, injecting our classic XSS payload, and commenting out the rest of the code.

One way to choose this type of scenario is based on the length limitations set by the application.

Let’s use the first way mentioned above to craft the XSS payload.

Improvised Payload 2: Using HTML5 Attribute

onmouseover is one of the HTML attributes that can be used with HTML tags, the moment the mouse hovers over the code, the javascript alert() function gets triggered.

Enter the above-improvised payload in the input field and click on the “Submit” button.

Output:

For a moment, things seemed like nothing happened, and the application behaved normally as expected.

Take your mouse, hover over the input field, and observe. Immediately, a pop-up message is prompted, as shown below.

yay!!!, our XSS payload worked and the application displays the pop-up message. This confirms that the application is still vulnerable to the reflected cross-site scripting vulnerability.

Will view the page source code to check how our payload got injected and changed HTTP response behavior. Right-click and select “View page source”, then search for the injected payload string.

Observe that the double quote has closed the value field, then appended the HTML attribute element for the input tag with the “onmouseover” event along with the javascript code, then closed the double quote to further align with the HTML code.

We have successfully confirmed that the application is still vulnerable to cross-site scripting vulnerability.

Let’s continue and try out the second method mentioned above to craft the XSS payload.

Improvised XSS payload 3: Classic XSS with syntax correction

The above payload is the same as we used earlier but with minor modifications.

In prefix, a double code followed by a greater than arrow mark to close the input form field. Then at the end of the script code append the HTML comment code, this will comment out all the next code after our HTML script tag.

Enter the above payload in the input field and give it a try.

Output:

Immediately, a pop-up message is displayed confirming that the XSS payload still works.

Click “OK”, then Right-click and select “View page source”, then search for the injected payload string.

As expected, observe the HTML input tag is closed, then injected with our classic XSS payload and followed by commenting out all the rest of the code after the HTML script tag.

By this, we have successfully exploited the cross-site scripting vulnerability challenge 4.\

Summary

In this article, we learned how poorly implemented validations can still be bypassed by improving the XSS payload and trying different possible combinations. Also, there is no need that the default XSS payload needs to work out of the box, the payload needs to be tweaked based on the scenarios to make it work.

Keep learning! :D