The Browser Options


The BrowserBruter has following options which affects the working of browser -

Browser Options:
  --chrome-binary /path/to/chrome
                        Use this switch to provide your local/custom chrome browser.
  --chrome-driver /path/to/chromedriver
                        Use this switch to use your local/custom chromedriver.
  --headless            Use this switch to run browser in headless mode (No GUI).
  --no-css              This switch will tell Browser Bruter to drop the requests to .css files and it will not load .css files and remove <style> tag.
  --proxy http://proxyaddress:port/
                        Set proxy for traffic, for example give IP:PORT of Burpsuite to send traffic to burpsuite.
  --remove-images   This switch tells BrowserBruter to not load audio, video and image (.png, .img, .ico, .mp4, .gif, .mp3 etc) files. By default it discards these files to save time and load pages faster.
  --chrome-options blink-settings=imagesEnabled=false,disable-notifications
                        Custom comma separated list of options which will be passed to chrome. [This will override in-built options in Browser-Bruter that are passed to chrome]
  --anti-bot            This switch tells BrowserBruter to use avoid any chrome options and use raw undetected chrome driver to avoid bot detection, by default Browser-Bruter uses custom Chrome options along with undetected chrome driver like disabling xss protection along with undetected chrome driver
  --no-anti-bot         Completely removes any anti bot detection evasions.
  --new-instance        Start new fresh instance of browser for each new payload [Fuzzing process's iteration] useful in bypassing the invisible captchas.

Providing your own local Browser and Driver to run using --chrome-binary and --chrome-driver options

You can use your local Browser or custom chrome browser instead of the one pre-built in Browser Bruter. You have to provide the path of the chrome binary to this option and the Browser Bruter will use the specified browser for running the attack.

Similarly, You can also provide your own chrome driver using --chrome-driver option.

NOTE: When you provide your own chrome driver, you have to make sure the version of driver and version of browser are satisfied, some newer driver does not run the older browsers and vice versa.

NOTE: As of now, if you use your custom chrome driver, the anti bot features will be disabled, you have to provide your custom chrome options using --chrome-options switch to enable them. This happens due to the Browser Bruter uses undetected chrome driver.

python3 BrowserBruter.py --elements uname,pass --payloads fuzz.txt --attack 1 --target http://localhost/login.php --button submit --fill uname,pass --chrome-binary res/chrome/chrome --chrome-driver res/chrome/chromedriver

Routing HTTP traffic through proxy (Burp, ZAP) using --proxy option


You can route browser's HTTP traffic via any proxy like Burp or ZAP using --proxy option.

You have to specify the the IP and Port of the proxy in following format - http://IP:PORT/

Following is the demonstration of routing traffic via BurpSuite -

python3 BrowserBruter.py --elements username,password --payloads fuzz.txt --target http://localhost/login1.php --button btn-default --attack 1 --fill username,password --proxy http://localhost:8080/

Running browsers in headless mode using --headless switch


The --headless switch will simply run the browser without any GUI. Although looks simple, this will drastically improves the speed of BrowserBruter and Browser Instance and overall saves the system resources.

It is highly recommended to always run the BrowserBruter in headless mode when running max threads. i.e. --threads 20.

Following is an demonstration of effect of this switch

  • Without --headless

  • With --headless

Removing styles, colors and design using --no-css option


While fuzzing the Web Pages using The BrowserBruter, we usually don't require any fancy color or top notch UI experience provided by web application's tons of CSS code.

Removing CSS reduces the overhead of loading parsing css and rendering rich UI increasing overall performance and loading speed of web pages.

We can use --no-css switch to tell The BrowserBruter to remove CSS during fuzzing process. The BrowserBruter will drop HTTP request for all .css files reducing the HTTP traffic and will remove <style> tags.

However, keep in mind that inline css will not be removed, because removing inline css from all elements it self is long process.

Following is demonstration of --no-css switch

  • Without --no-css switch
  • With --no-css switch

Loading images using --remove-images


By default, The BrowserBruter will load following static media files -

'.ico', '.png', '.img', '.jpg', '.svg', '.jpeg', '.jfif', '.pjpeg', '.pjp', '.gif', '.apng', '.avif', '.webp', '.bmp', '.cur', '.tif', '.tiff', '.mp3', '.mp4', '.avi', '.mkv', '.webm', 'ogv'

To reduce the overhead of loading static media. However, for any requirements, if you want to not load this files, You can use --remove-images switch.

Specifying custom chrome options using --chrome-options


The BrowserBruter by default starts Chromium browser using following options

 disable-ipc-flooding-protection
 disable-xss-auditor
 disable-bundled-ppapi-flash 
 disable-plugins-discovery 
 disable-default-apps 
 disable-prerender-local-predictor 
 disable-sync 
 disable-breakpad     
 disable-crash-reporter 
 disk-cache-size=0 
 disable-settings-window 
 disable-notifications 
 disable-speech-api 
 disable-file-system 
 disable-presentation-api 
 disable-permissions-api 
 disable-new-zip-unpacker 
 disable-media-session-api 
 no-experiments 
 no-events 
 no-first-run 
 no-default-browser-check 
 no-pings 
 no-service-autorun 
 media-cache-size=0 
 use-fake-device-for-media-stream 
 dbus-stub 
 disable-background-networking 
 disable-features=ChromeWhatsNewUI,HttpsUpgrades 
 proxy-bypass-list=0.0.0.0 
 ignore-certificate-errors 
 disable-dev-shm-usage
 disable-blink-features=AutomationControlled

Apart from these, if you want to specify any options you can do it using --chrome-options option.

Note: Using this option will override all the default options.

You can specify custom chrome options in comma separated list as follows -

--chrome-options ignore-certificate-errors,disable-dev-shm-usage

This is also helpful when you don't want any of the default options and want to remove any of them.

Tackling Bot Detection using --anti-bot and --no-anti-bot options


By default, The BrowserBruter has few tricks under its sleeves to tackle the bot detection.

For example, if we disable all anti-bot detection mechanism, the difference is pretty clear.

Without any anti-bot detection - using --no-anti-bot switch

Here's what is happening -

  1. The BrowserBruter does not use the undetected-chrome driver
  2. It uses browser with normal chrome driver

The --no-anti-bot switch disables every anti-bot detection mechanism, This is not recommended to use as the default BrowserBruter configurations will tackle most of the scenarios.

Here's what is happening -

  1. The BrowserBruter uses the undetected-chrome driver.
  2. It uses browser with default chrome options specified in BrowserBruter.
  3. Overall optimal solution.
Using --anti-bot switch

Here's what is happening -

  1. The BrowserBruter uses the undetected-chrome driver.
  2. All of the default chrome options are overridden and total control is given to the undetected-chrome driver.
  3. Useful when there are strict anti-bot detection mechanisms are implemented which are preventing the the fuzzing process by detecting the use of selenium.

Tackling Invisible Captchas using --new-instance switch


The --new-instance switch forces the BrowserBruter to close the browser instance after each fuzz attempt and spawn new fresh instance of next attempt.

For better understanding, here is a live effect of this switch

Here's what is happening,

  1. The BrowserBruter first spawns the Chromium browser instance.
  2. Then it injects the payloads into specified fields.
  3. Then it submits the form by pressing --button element.
  4. Then for next payload injection, it closes current browser and spawns new fresh browser instance.
  5. This is repeated for all payloads and at each fuzz attempt.
Why we even need this?

There might be some scenarios where an invisible captcha is implemented which prevents the BrowserBruter from fuzzing the web page, in such case this can come handy. The con of running the BrowserBruter in this mode is it takes longer for fuzzing to finish as we are spawing and initializing each browser instances at each fuzz attempt. Though other captchas can be solved using running the BrowserBruter in --interactive mode. Learn more here


Hope on to the next section to learn about the Debug Options.

results matching ""

    No results matching ""