8 Free Security Testing Tools You Must Know About

What are Security Testing Tools?

In the software world, security testing involves testing a software application to identify vulnerabilities and misconfiguration that could be exploited by an attacker. These could be as simple as a default admin password, or as complex as an injection vulnerability deep in the application code. 

The objective of security testing is not only to discover vulnerabilities but also to provide clear, actionable information on how to remediate them and prevent future attacks. Ideally, security testing should happen early in the development lifecycle – this can prevent security issues from ever reaching a production environment, and also makes these issues simpler and less expensive to fix. This pattern is known as shifting security left.

There are many types of security testing – we’ll introduce powerful security tools from each of these categories:

In this article, we cover the following security testing tools:

1. Bright Security
2. OWASP ZAP
3. Wapiti Scanner
4. Arachni
5. Vega Scanner
6. BeEF (Browser Exploitation Framework)
7. Wfuzz
8. Nogotofail

1. Bright Security

Deployment model: on-premise and cloud

Learn more: Bright Security DAST

Bright Security is a security testing platform that can scan web applications, APIs (REST/SOAP/GraphQL) to help enhance DevSecOps and achieve regulatory compliance. The platform provides real-time, actionable reports of vulnerabilities, with zero false positives. In addition, its ML-based DAST solution provides an automated solution to identify business logic vulnerabilities.

Bright Security empowers developers to incorporate DAST into their unit testing process so they can resolve security concerns as part of an agile development process. The Bright DAST platform integrates into the SDLC fully and seamlessly: 

  • Test results are provided to the CISO and the security team, providing complete visibility into vulnerabilities found and remediated
  • Tickets are automatically opened for developers in their bug tracking system so they can be fixed quickly

Start testing with Bright Security today – get a free account

2. OWASP ZAP

Deployment model: on-premise

GitHub: https://github.com/zaproxy/zaproxy 

OWASP ZAP (short for Zed Attack Proxy) is an open source web application security scanner. It was named a “flagship project” in the Open Web Application Security Project (OWASP). It is intended both for users who are new to application security and professional penetration testers.

ZAP can be used as a proxy server, allowing users to manipulate traffic flowing through the tool, including HTTPS traffic. It can also run in daemon mode, controlled via the REST API.

Key features include:

  • GUI control panel
  • Traditional and AJAX web crawlers
  • Automatic active and passive scanning
  • Forced browsing
  • Fuzzing
  • WebSocket scanning support
  • Support for multiple scripting languages
  • Support for Plug-n-Hack via its plugin-based architecture
  • Online free marketplace where the community can add features

3. Wapiti Scanner

Deployment model: on-premise

GitHub: https://github.com/wapiti-scanner/wapiti 

Wapiti is a command-line application that crawls web pages and searches for scripts or forms that enable user inputs and could be vulnerable to attack.

It is a black box vulnerability scanner that scans pages of a deployed web application from an attacker’s perspective, extracts links and forms, and attempts to access them in randomized ways using a fuzzer. It delivers malicious payloads and looks for error messages, special strings, or unusual behavior that can be exploited by attackers.

Key features include:

  • Vulnerability reports in HTML, XML, JSON, TXT, and CSV formats
  • Ability to pause and resume a scan or attack (based on sqlite3 sessions)
  • Color coding in terminal outputs to highlight vulnerabilities
  • Multiple levels of verbosity in reporting
  • Easy enabling or disabling of attack modules
  • Easily adding payloads by appending a line to a text file
  • Configurable level of concurrency for HTTP requests

Learn more in our detailed guide to mobile security.

4. Arachni 

arachni

Deployment model: on-premise

GitHub: https://github.com/Arachni/arachni 

Arachni is a web application security scanning tool written in Ruby. It enables auditing and inspection of client-side code through an integrated browser environment, and supports complex web applications that make use of technologies like HTML5, JavaScript, AJAX, HTML5, and DOM manipulation.

While scanning, Arachni monitors and learns various factors about how your web application behaves, assesses the reliability of results, and intelligently identifies false results. Unlike other scanners, it takes into account the dynamic nature of a web application and can detect and adapt accordingly to changes in the path web application’s execution paths. This allows for detection of attack and input vectors that typically only humans can detect.

Arachni covers a wide variety of use cases, including:

  • Simple command-line scanner utilities
  • High-performance scanner grids
  • Scripted auditing
  • Multi-user multi-scan collaboration

5. Vega Scanner

Vega

Deployment model: on-premise

GitHub: https://github.com/subgraph/Vega 

Vega is an open source security scanner and security testing platform for web applications, written in Java. It includes an automated scanner for quick testing, and an intercepting proxy for tactical inspection. It provides a GUI interface and runs on Linux, OS X/MacOS, and Windows. It can be extended using a JavaScript-based API.

Vega helps find and verify vulnerabilities such as:

  • SQL injection
  • Reflected and stored cross-site scripting (XSS)
  • Unintentional disclosure of secrets
  • Remote file inclusion (RFI)
  • Shell injection
  • Weaknesses in SSL/TLS security settings

6. BeEF (Browser Exploitation Framework)

Deployment model: on-premise

GitHub: https://github.com/beefproject/beef 

BeEF stands for Browser Exploitation Framework. It is a penetration testing tool focused on web browsers. BeEF enables expert penetration testers to use client-side attack vectors to evaluate the security mechanisms of a protected environment. 

Unlike other security frameworks, BeEF looks for potential exploits in the context of a common attack vector: the web browser. It connects to one or more web browsers and uses them to execute command modules and attempt attacks against the network perimeter and client systems.

Related content: Read our guide to websocket security.

7. Wfuzz

Deployment model: on-premise

GitHub: https://github.com/xmendez/wfuzz 

Wfuzz makes it possible to evaluate web applications in a flexible way by injecting payloads (arbitrary inputs which can come from any data source) into any field of an HTTP request. This allows sophisticated attacks against various web application components such as URL parameters, authentication, forms, directories, files, and HTTP headers.

Key features include:

  • Application vulnerability scanner and ability to exploit vulnerabilities in web applications.
  • Modular plugin framework that makes it easy for Python developers to contribute new plugins.
  • Simple language interface to previous HTTP requests or responses, whether performed by Wfuzz or other tools like Burp Suite. This enables both manual and semi-automated testing, with full control over every step of the testing process, and without reliance on the underlying web application scanner.

8. Nogotofail

Deployment model: on-premise

GitHub: https://github.com/google/nogotofail 

Nogotofail is a tool that secures applications against known SSL/TLS vulnerabilities and misconfigurations. It can be used to test network security issues on any device that relays or processes network traffic. 

Nogotofail runs on Android, iOS, Linux, Windows, Chrome OS, OS X/MacOS, and almost any device with Internet connectivity. It provides a client that lets you configure settings and receive notifications on both Android and Linux. The attack engine itself can be deployed as a router, VPN server or proxy.

Its primary use cases are:

  • Finding bugs and vulnerabilities in networks
  • Verifying fixes and identifying regressions in a network environment
  • Mapping out network data flows and understanding which applications and devices are generating traffic

Conclusion

Security testing should be a critical part of any organization’s cybersecurity strategy. While in the past security testing was a one-time, annual, or quarterly activity, usually conducted as a formal penetration test, organizations are increasingly adding security testing into their day-to-day routine. 

In a DevSecOps organization, security tests do not happen once per quarter – they happen many times a day. Ideally, every code change by a developer should undergo security testing, even before it is committed to a code repository. Every build created by a continuous integration (CI) server should undergo automated security testing as part of its initial sanity check.

Learn how Bright Security is helping make this vision possible

Pen Testing with Python: Pros and Cons

Table of Content

  1. What is Pen Testing?
  2. Should I Use Python for Pen Testing?
  3. Python Pen Testing Examples
  4. Conclusion

What is Pen Testing?

Pen Testing is a process of protecting your system from cyber attacks. This is achieved by executing various malicious programs in order to exploit and learn about any possible vulnerabilities that might occur on your system. 

These can be performed manually or automatically, but the idea remains the same – to test and safely exploit all vulnerabilities on your system. 

The process of penetration testing is carried out by ethical hackers. As the name itself suggests, these are hackers who know how the attacker might think, and thus they can come up with a solution to defend and protect against malicious activities.

Should I Use Python for Pen Testing?

Python is perhaps the most used programming language when it comes to pen testing. This is partly because there is an enormous amount of external python libraries available. These libraries make life that much easier for the pentester. 

Another bonus of using Python is its simplicity. While most programming languages require extensive research in order to catch up with the basics, that’s not the case with Python. It’s a pretty intuitive and well-designed language, allowing you to quickly catch up with some more complex ideas and implementations of it. 

Not only that, but if you’re using it properly, Python can be extremely fast in its execution, making a big difference in the long run, especially on a large-scale project.

Pen Testing Attacks and Exploits with Python

As we explained in the previous sections, Python should be your go-to programming language if you want to try your hand at pen testing. 

What’s important with pen testing attacks when using python is that you follow the plan at all times. It usually consists of four different phases, which are:

  • Planning phase
  • Discovery phase
  • Attack phase
  • Reporting phase

The first phase is preparing the groundwork for the attack. This means defining the scope of your attack and the general idea and the goal behind it. 

The discovery phase – also known as fingerprinting – really speaks for itself. The idea is to find out as much as possible about the system you want to penetrate. This part is mostly research in order to find out the potential weaknesses of the system. 

Attack phase means that you’re launching an attack on vulnerable parts of the system and extracting as much data as possible.

And, of course, the reporting phase means that you compile a report of all potential and existing vulnerabilities. Every report has to be very detailed and specific, otherwise it won’t help much with the further protection of the system.

Python Pen Testing Examples

Pen testing with Python gives you an unlimited array of possibilities. This means that you can be very creative in finding different ways of approaching a problem of penetration testing. 

The first thing you should do when pen testing with python is to look into the existing libraries that will make your life much easier. Here are some of the most popular tools that you can use for this purpose:

  • Python Nmap – helps you easily manipulate nmap scan results
  • BeautifulSoup – used to launch attacks against web applications. BeautifulSoup helps you to quickly identify the crucial parts of the response
  • Scapy – supports developing and transmissions of custom network packets, utilizing exploitation over the network
  • Monda – creates ready-made code that you can use for exploits and simplifies many smaller tasks in the process

One thing that might help you out a lot when pen testing with Python is knowing some other languages so you could ease the process for yourself. JavaScript knowledge could come in handy once you get to pen testing web applications as it allows you to quickly identify and understand the application you’re attacking with your python code. 

Conclusion

If you’re serious about penetration testing, then python is the way to go. With its endless libraries, it ensures you have all the tools you need at your disposal. Not only that, but it’s the most popular pen testing language out there. So, even if you get stuck along the way, there’s always help available on the internet. 

If you prefer automated pentesting, then look no further than Bright! You can sign up for a free account today, and get started immediately because our application is well-suited for developers, meaning that you don’t have to have in-depth knowledge of web security in order to keep your application secure. 

How to test for Cross-Site Request Forgery?

What is Cross-Site Request Forgery Test?

Cross-Site Request Forgery (CSRF) testing is the procedure of finding and remediating CSRF vulnerabilities in web applications. A CSRF attack tricks users into submitting a malicious request. By performing a CSRF attack, the attacker inherits the identity and privileges of the victim to perform an undesired function on behalf of the victim. For most sites, the browser requests automatically include any credentials associated with the site. If the user is currently authenticated to the site, the site will have no way to distinguish between a legitimate and a forged request.

Testing for cross-site request forgery can be conducted either manually or by using automated tools. 

In this article you will learn:

What impact can a CSRF attack have?

With no protection from this attack, cross-site request forgery can expose and compromise the confidentiality and integrity of the application’s userdata. 

In many cases, a CSRF attack violates how the website handles it’s sessions. This translates to attackers being able to hijack a user’s session in order to perform actions that the user did not intend to take. As an example, an adversary can trick a user into changing their account password to a password of the attacker’s choosing, or change the shipping address to an address the attacker controls without the user’s knowledge or permission resulting in the loss of the trust of end-users. 

How does a Cross-Site Request Forgery attack work?

There are numerous ways in which an end user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a valid malicious request for the victim to execute.

Let’s consider the following example:

A user wants to transfer $50 to a friend. The bank application is vulnerable to CSRF. The attacker wants to trick our user into transferring the money to his account instead of the friend’s account. To do that, the attacker needs to:

  • Build an exploit URL or script
  • Trick the user into executing the action with social engineering

GET Scenario

If our bank application was designed to use GET requests to transfer parameters and execute actions, the money transfer operation might be reduced to a request like:

GET http://vulnerable-bank.com/transfer.do?acct=Nedim&amount=50 HTTP/1.1

The attacker first constructs the following exploit URL which will transfer $50,000 from the victim to the attacker’s account. The attacker manipulates the original command URL and replaces the beneficiary name and the transfer amount:

http://vulnerable-bank.com/transfer.do?acct=ATTACKERNAME&amount=50000 HTTP/1.1

Via social engineering, by sending the victim an email with HTML content or perhaps by including the exploit URL on another page for example, the attacker can get the unassuming victim to load their URL

A real life example of CSRF attack on an application using GET was a uTorrent exploit from 2008 that was used on a mass scale to download malware.

POST Scenario

Let’s assume that our bank uses POST for transferring parameters and executing actions. The vulnerable request would look like this:

POST http://vulnerable-bank.com/transfer.do HTTP/1.1
acct=Nedim&amount=50

Such a request can be delivered using a form tag:





This form relies on the user clicking the submit button, but it can also be executed automatically using JavaScript:


Other HTTP methods

APIs in modern web applications frequently use other HTTP methods, such as PUT or DELETE.

Now let’s assume that our vulnerable bank application uses PUT that takes a JSON block as an argument:

PUT http://vulnerable-bank.com/transfer.do HTTP/1.1

{ "acct":"Nedim", "amount":50 }

We can execute this request by using JavaScript embedded into an exploit page:


Thanks to the same-origin policy restrictions, this request will not be executed by modern browsers. This restriction is enabled by default unless the target website explicitly opens up cross-origin requests from the attacker’s origin by using CORS with the following header:

Access-Control-Allow-Origin: *

Manual testing for Cross-Site Request Forgery vulnerabilities

If you want to discover if the session is insecure you will need to examine the application's session. If session management is on the user side, indicating information is available to the browser, then the application is vulnerable. “Client-side values” refer to HTTP authentication credentials and cookies. 

Accessible resources via HTTP GET requests are undoubtedly vulnerable, although POST requests tend to be automated via JavaScript and are exposed and vulnerable, therefore the use of POST only is not enough to fix the occurrence of CSRF vulnerabilities.

Automated Tools for CSRF testing

1. Bright

Bright is a Dynamic Application Security Testing (DAST) scanner.  It can be integrated across the development pipelines to test your web applications and APIs, automating and simplifying the detection and remediation of CSRF and many other vulnerabilities

By shifting DAST scans left and integrating them across the CI/CD, developers and application security professionals are able to detect vulnerabilities as early as possible, to remediate them before they hit production. This allows developers to adopt the solution and use it throughout the software development lifecycle -  SDLC.

Bright's CSRF test first checks if there is any CSRF protection implemented, by checking if the target has "Access-Control-Allow-Origin'' header misconfiguration or missing "Origin" header. The second phase checks if the CSRF token itself is missing inside the request query. If all these steps are confirmed, the final step executes the requests, confirming and validating the vulnerability has been successfully exploited, to ensure there are no false positives.

2. OWASP ZAP

OWASP ZAP is an open-source web application security scanner, used predominantly by professional penetration testers. A great tool but not developer friendly.

ZAP detects anti-CSRF tokens solely by attribute names - that is considered to be anti CSRF tokens and is configured using the Anti CSRF in options. When ZAP detects these tokens it records the token value and which URL generated the token.

3. CSRF Tester

CSRF Tester is a project by OWASP, created by a group of developers for developers, to verify the integrity of HTTP requests in their web applications. CSRF Tester provides a PHP library and an Apache Module for cautious mitigation.

4. Pinata-csrf-tool

Intended to be used by advanced application security professionals. It generates the proof of concept CSRF HTML given an HTTP request to automatically discover whether it is a GET or a POST request with further validation for standard POST and Multipart/form POST. The tool creates HTML corresponding to the type of the request.

Conclusion

Many tools on the market can help you discover and remediate CSRF vulnerabilities but the question is how reliable and developer friendly they are.

With Bright you can easily test for CSRF, the OWASP Top 10 vulnerabilities and many more in just a few clicks. Bright is built from the ground up to put security testing into the hands of developers, integrated seamlessly into their environment and across the CI/CD.

Bright’s automatic validation of every exploitable vulnerability it detects removes false positives and the alert fatigue that comes with it. Developers get immediate results with developer friendly remediation guidelines to prioritise and fix the security vulnerabilities before they hit production. The security team also gets an accurate snapshot of their cyber posture without the need for manual validation, removing the largest bottleneck organisations face currently.
Want to see Bright in action? Get a free account here – https://app.brightsecurdev.wpenginepowered.com/signup

How to Prevent Cross-Site Scripting Attacks?

What is Cross-Site Scripting Prevention?

Cross-site scripting prevention is the process of detecting and remediating XSS vulnerabilities in your websites or web applications before they hit production. The detection of XSS vulnerabilities can be done automatically, using an automated vulnerability scanner, or manually by performing penetration tests. In this article you will learn the best practices for cross-site scripting prevention and how you can implement them immediately. At the end of the article, you will also find a link to a free, developer-focused vulnerability scanner so you can start detecting and remediating cross-site scripting vulnerabilities early and often, as part of your development pipelines

In this article, you will learn:

How does cross-site scripting work?

Cross-Site Scripting (XSS) attacks are a form of injection attack, where malicious scripts are injected into trusted web applications. 

An attacker can use the web application to send malicious code, typically in the form of a browser side script, to a different end user, resulting in an XSS attack.

XSS vulnerabilities are very common, occurring where a web application uses input from a valid user contained within the generated output, but without the appropriate validation or encoding.

With the malicious script sent to the user, their browser is unable to categorically know that the script should not be trusted, and subsequently executes the script. This script can then access a multitude of data, including any cookies, session tokens, or indeed any other sensitive information that may be retained by the browser for that site. 

What are the types of XSS attacks?

There are three main types of XSS attacks:

  1. Reflected XSS: malicious script comes from the current HTTP request
  2. Stored XSS: malicious script comes from the website’s database
  3. DOM-based XSS:  where the vulnerability exists in client-side code rather than server-side code.

How important is Cross-site scripting prevention?

The damage from exploiting an XSS vulnerability depends on the sensitivity of the data your site handles. Here are some examples where hackers exploited  XSS vulnerable apps:

  • Spreading worms on social media: Facebook, Twitter and YouTube have all been successfully attacked in this way.
  • Session hijacking: Malicious JavaScript may be able to send the session ID to a remote site under the hacker’s control, allowing the hacker to impersonate that user by hijacking a session in progress.
  • Identity theft: If the user enters confidential information such as credit card numbers into a compromised website, these details can be stolen using malicious JavaScript.
  • Denial of service attacks and website vandalism.
  • Theft of sensitive data, like passwords.
  • Financial fraud on banking sites.

Cross-site scripting protection

Escape dynamic content

Usually, when a web page is rendered, dynamic content is woven into HTML. If the dynamic content is improperly treated, an attacker can use that to construct a stored XSS attack. The attacker would abuse an editable field by inserting some malicious JavaScript code, which is evaluated in the browser when another user visits that page.

You may not want your users to author raw HTML unless your site is a content-management system. Escape all dynamic content coming from a data store, so the browser knows it is to be treated as the contents of HTML tags, as opposed to raw HTML.

Escaping dynamic content generally consists of replacing significant characters with the HTML entity encoding:

” &#34
# &#35
& &#38
‘ &#39
( &#40
) &#41
/ &#47
; &#59
< &#60
> &#62

As you will see in the code samples below, most modern frameworks will escape dynamic content by default.

By escaping editable content in this way, the content will never be treated as executable code by the browser. This will prevent most XSS attacks.

Whitelist values

If a dynamic data item can only take a handful of valid values, restrict the values in the data store. Also, make sure your rendering logic only permits known, proper values.

An example where you may want to use this approach is by asking a user to select their country from a dropdown list,, instead of having them typing it in manually.

Implement a content-security policy

Modern browsers support Content-Security Policies. Content-Security Policies allow the author of a web-page to control where JavaScript and other resources can be loaded and executed from.

In order for an XSS attack to be possible, the attacker has to be able to run malicious scripts on a user’s web page – either by injecting inline