Skip to content
Andrew Horton edited this page Jun 13, 2019 · 17 revisions

The next release of WhatWeb will be version 0.5.1. No release date is planned at this stage.

The WhatWeb 0.5.1-dev branch is available for the impatient.


The current focus on development is refactoring the WhatWeb code-base into Modules.


SSL Certificate Support

Let people specify an SSL/TLS certificate.


MD5 Matches

Implement aggressive md5 hash matches for version detection in popular open source software. WAFP and BlindElephant style.


Aggression Level Five

Aggression level 5 will be used for requests which are directly related to compromising the security of a device or service without exploitation.

This includes requests designed to discover weak access controls caused by misconfiguration and requests designed to retrieve information from known information disclosure issues.

  • Update Cisco-IOS plugin to determine if the device requires authorization using /level/[INTEGER]/exec/- requests
  • Attempt login with default www-authorization credentials basic|digest base64(user:pass)
  • Allow plugins to set custom headers, such as www-authenticate and cookies

Categorization

See the Categorization section on the Discussion page for more information, including suggested category names.

Goals of categorization / tagging:

  • Run all plugins for a certain category:

./whatweb -c SCADA

  • Display and group by categories in logging/output:
http://example.com [200]
HTML-Elements: Title, Meta-Generator, Script, Frame
Server: Apache
Web-App: Wordpress
  • Multiple categories for plugins:

    • ordered by priority, ie, where conflicts exist in grouping, go with the first option.
category ["SCADA", "Device"]
  • SSL Certificates

    • Extract hostname from ssl certificates
    • Should we test ciphers? Hmm.. probably not.

Plugin Errors and Crashes

These problems have not yet been allocated to a developer to be resolved.

Wordpress

bcoles: The wordpress plugin currently iterates through links and checks whether they're relative by checking for "/wp-content" or @base_uri + "/wp-content"

A cleaner solution would be using two regexps; one to compare @body to "/wp-content" and one to compare @body to @base_uri + "/wp-content"

This avoids having to convert long strings or potentially incompatible strings into URI objects.

$ ./whatweb 186.202.17.207 --debug
Exception `URI::InvalidURIError' at /usr/lib/ruby/1.8/uri/common.rb:436 - bad URI(is not URI?): http://www.tedxmataatlantica.com.br/wp-content/uploads/2011/05/Mata-Atlântica-195x110.jpg
Exception `URI::InvalidURIError' at /usr/lib/ruby/1.8/uri/generic.rb:732 - bad URI(is not URI?): http://www.tedxmataatlantica.com.br/wp-content/uploads/2011/05/Mata-Atlântica-195x110.jpg
ERROR: Plugin WordPress failed for http://186.202.17.207. bad URI(is not URI?): http://www.tedxmataatlantica.com.br/wp-content/uploads/2011/05/Mata-Atlântica-195x110.jpg
Exception `URI::InvalidURIError' at ./whatweb:751 - bad URI(is not URI?): http://www.tedxmataatlantica.com.br/wp-content/uploads/2011/05/Mata-Atlântica-195x110.jpg
/usr/lib/ruby/1.8/uri/generic.rb:732:in `merge': bad URI(is not URI?): http://www.tedxmataatlantica.com.br/wp-content/uploads/2011/05/Mata-Atlântica-195x110.jpg (URI::InvalidURIError)
        from /usr/lib/ruby/1.8/uri/common.rb:522:in `join'
        from /usr/lib/ruby/1.8/uri/common.rb:521:in `each'
        from /usr/lib/ruby/1.8/uri/common.rb:521:in `join'
        from ./plugins/wordpress.rb:63:in `passive'
        from ./plugins/wordpress.rb:61:in `each'
        from ./plugins/wordpress.rb:61:in `passive'
        from ./lib/plugins.rb:134:in `x'
        from ./whatweb:742:in `run_plugins'
        from ./whatweb:717:in `each'
        from ./whatweb:717:in `run_plugins'
        from ./whatweb:1374
        from ./whatweb:1253:in `initialize'
        from ./whatweb:1253:in `new'
        from ./whatweb:1253