What the Tech behind this Website? Wappalyzer Knows

Trying to figure out what technologies/frameworks a web app is built upon is an important part of application security, especially pen testing.  It's something that should be done in the reconnaissance phase of an assessment.  Knowing what an application is using under the covers is a definite advantage in your quest to pwn it.

Trouble is, it's not so easy anymore.  There is a vast array of technologies that make up today's web application development landscape.  Not only are there are different types of web servers, application servers, and  programming languages, you also have to consider different development platforms (Java vs. .NET vs. something else), client-side JavaScript frameworks (Angular vs. React vs. something else), authentication protocols (OAuth vs. Kerberos vs. one-off vs. API token vs. something else), CMSs, CDNs, advertising networks, analytics engines, and so on.  Is your head spinning yet?

For quick feedback on what technologies a web application is using, I recommend the Wappalyzer browser extension.  It is available for both Chrome and Firefox.  Once installed, you will see the following icon in your browser's toolbar: 

Click this icon and you'll see a categorized listing of different types of technologies used by the website currently loaded in your browser.  Here is an example:

I have personally found this extension to be very useful... for pen testing or even when you see an interesting-looking site.  Find out what it's built on!  This extension thankfully works with Firefox 55 and later, which is something that can't be said of many popular Firefox extensions nowadays (this is thanks to Mozilla's shift to use the cross-browser WebExtensions API.

One last important note about Wappalyzer - you probably want to uncheck the option (shown below) where you send them "anonymous" reports for research.

Wordlist for Common Pet Names

If you are testing web applications for security, be sure to examine the Forgot Password functionality and attempt to subvert it.  It's another way that users can authenticate to the app and is often less secure than the primary method.  First you'll need to enumerate usernames (try the username wordlists I made available a while ago).  Once you have some valid usernames, the Forgot Password functionality will often present you with a challenge to answer one of the user's personal security questions.

One of the most common security questions you see is "What was the name of your first pet?".  If the application doesn't limit the number of attempts, you have a very good chance at answering this question by iterating through different names with a tool like Burp Intruder.  The last time I did this successfully, "Rocky" was the name of the user's pet.

You need big list of common pet names to do this.  That's exactly what I'm providing here for your download pleasure.  My wordlist currently has over 1,400 pet names.

  Click here to get the pet name wordlist

Enjoy!  Obviously my list can't cover every conceivable pet name, but please let me know if you think I'm missing a common one.

Wordlists for Common Usernames

I made some wordlists a while ago containing common usernames.  They have proven very useful to me when doing application penetration testing, specifically they are great to use as the payload for Burp Intruder.

I created the lists by taking the 10,000 most common last names in the United States and prepending a single letter (for example "dferguson" appears in the usernames-d.txt wordlist).  There are wordlists for all letters except "i", "q", "x", and "z" (frankly, there aren't many first names that begin with those letters so it's a waste of time to try them).

 Click here to get the username wordlists (zip)

One scenario where you might leverage these wordlists is a web application where the login page returns a different error message depending if a valid username is received versus and invalid username.  Run Intruder on the login request and you can probably reap a nice set of valid accounts.

You'll also find a special wordlist called usernames-top100-each-letter.txt.  This is perfect when you have limited time and want to maximize your potential to find a valid account.  And there's another list called usernames-generic.txt, which could help you discover some test accounts.  Of course you can combine these wordlists any way you want (even concatenate them together and try the whole darn thing).

Things get a little more complex if the web app requires an email address for login.  You could certainly append "@gmail.com", "@yahoo.com", "@aol.com", etc. to the usernames.  Separate wordlists could be created for each email domain, or you could just leverage the power of Burp Intruder to append the domain on the fly.

Think of Base64 Data as Plain Text

I think there is still confusion in the minds of many developers about Base64 encoding.  It's not encryption.  It doesn't offer any protection of the data at all.  It's trivial to decode with Burp Suite, a desktop utility, or a website such as this.

When testing a web application for security, be sure to decode any Base64-encoded strings you see (often they will have one or two "=" at the end).  You may find the resulting data is gibberish, which probably means it's encrypted or hashed.  Or you may find sensitive user data developers were hoping to hide.  You also might find technical information about the deployment infrastructure or a clue that leads you to another area of the application that has a security hole.

What is Base64 encoding?  Just a way to encode ANY data so it can be represented as plain ASCII text.  This is convenient in many situations.  Email attachments are sent as Base64 data for example.  For every 3 bytes of data, encoding will get you 4 ASCII characters.  It works by first concatenating ("smooshing") the data together in binary form, then chunking it up into 6 bit sequences.  Padding with zeros is done if needed so the data is a multiple of 3 bytes. Each 6 bit sequence is converted to an ASCII character according to a standard Base64 encoding table.

Here is an example of Base64 encoding in action.

1) Start with some data. It could be Hex, Binary, ASCII, and so on.  Let's use the word "Hi".

2) Convert each byte to binary. We need to add one zero for padding in this case.
H : ascii code 72 / binary 01001000
i : ascii code 105 / binary 01101001
0 : binary 00000000

3) Smoosh the binary data together:
010010000110100100000000

4) Chunk it up into 6 bit sequences:
010010 000110 100100 000000
The decimal equivalent is:
18  6  36  0

5) Convert to Base64 using the table below. Any artificial trailing zero is represented by a "=".

The Base64 string is:  SGk=

Bug Editing Cookies in Web Developer Extension

Just a quick note I've been meaning to post about a small bug in Chris Pederick's Firefox Web Developer extension. It is a fantastic extension and I use it all the time, especially for working with cookies. Kudos to Mr. Pederick!

Unfortunately, what I noticed is that if you have "accept third-party cookies" unchecked in Firefox's privacy options, you can't edit cookies or add cookies. In fact it ends up deleting the cookies that you try to edit. D'oh!

This bug bit me a few times when I was trying to demonstrate session hijacking while teaching an application security class. This bug is a known issue and I'm hoping Chris can find a way to make it work in the next version. In the meantime, I will keep using the extension and trying to remember to enable third-party cookies whenever I teach the class.

Counting Lines of Code

Want some interesting metrics about your code? A nice little Windows utility called LOCmetrics could be just what you are looking for. When preparing for an application source code review, I usually need an estimate for the number of lines of code involved. I've found the numbers provided by development teams can vary significantly from what we actually see when we get the code. That is why I am going to start recommending they run LocMetrics.

LocMetrics has a simple GUI and works with C#, C++, Java, and SQL code. Run LocMetrics and it will dump out physical LOC, executable-physical LOC, and executable-logical LOC. Plus, you get bonus information like number of comment lines, blank lines, cyclomatic complexity (aka McCabe VG complexity) and LOC counts broken down by directory. The most important results are shown in the GUI itself and you get a HTML file containing more detail.

Here's a screen shot of the GUI:

I ran LocMetrics on a few Java libraries for comparison sake. Here are the results.

OWASP AntiSamy 1.3
Lines of Code = 4,576
Executable physical LOC = 1,972Executable logical LOC = 1,444
Cyclomatic complexity = 259
OWASP ESAPI 1.4.2
Lines of Code = 21,263
Executable physical LOC = 8,926
Executable logical LOC = 6,172
Cyclomatic complexity = 1,547

JSE 1.6.0_17 (java.* package only)
Lines of Code = 556,018Executable physical LOC = 200,567
Executable logical LOC = 136,076Cyclomatic complexity = 38,106

XSS via Cookie - How Severe?

Take a web application that sets a cookie. Now let's say the application takes the cookie value included in subsequent requests and outputs it into the HTML of the responses. Also assume this occurs with no authentication required and with no output encoding being done. Yes, this application is susceptible to reflected cross-site scripting.

I recently tested such an application. Interestingly, both HP WebInspect and Burp's active scanner reported the XSS vulnerability, but they were at opposite ends of the spectrum in terms of rating its severity. WebInspect rated it "critical" (the most severe rating), while Burp rated it as "information", which implies you don't even need to concern yourself about it.

So why the big disparity in these tools? Is it critically severe, or is it really no big deal? In my view, the answer is somewhere in between. This type of vulnerability is clearly very difficult to exploit. An attacker would somehow have to cause a victim's browser to send a script-injected cookie as part of a request to the vulnerable site. But regardless of the difficulty level, the application should properly encode the cookie value when it is written into the HTML page. Please let me know your opinion on how serious you think this type of vulnerability is.

IE Developer Toolbar Follow-Up

In an earlier post, I had commented on the fact that the IE Developer Toolbar has a problem in that it doesn't report cookies that are marked with the "HttpOnly" attribute. Well, as they said in the movie Independence Day, that's not entirely accurate (clip). There is an exception. The exception is when the cookie is a persistent cookie. The tool apparently doesn't utilize JavaScript in that case, and correctly reports the existence of the cookie. It's not actually a situation that would occur very often. Applications normally only need to mark *sensitive* cookies with HttpOnly, and sensitive cookies should not be persistent in the first place.

DirBuster Shoots and Scores!

There's a new tool I'm using as part of my security assessments and it is DirBuster. Developed by James Fisher and now available from OWASP, DirBuster's purpose is to sniff out the existence of directories and files on a server. Nothing more and nothing less. I did not have high expectations when grabbing a copy of DirBuster from the OWASP site. I was shocked at how many features it provides and how well it performs! Don't let the version number of 0.12 fool you. It's a very capable and polished tool.

DirBuster is written in Java (requires v1.6 or above), and the user interface is simple and intuitive. Even the look and feel is top-notch - much better than WebScarab or Burp Suite, for example, which use the default Swing look and feel. James wisely chose to use JGoodies, an open source library designed to make a more esthetically-pleasing Java user interface.

Once you start a scan, DirBuster goes to work. It lists directories and files as they are found. Since some servers don't return 404/Not Found for non-existent directories and files, DirBuster identifies positive hits by comparing each response to a base response for a known, non-existent resource.
Some of the bells and whistles in DirBuster include:

• configurable number of threads and ability to throttle up or down while a scan is running
• ability to scan for directories, files, or both
• file checks are done using extension(s) of your choice
• ability to narrow a scan to a particular subdirectory
• ability to do recursive scanning
• ability to load payloads from a file or to configure pure brute forcing
• customizable request headers
• support for basic, digest, and NTLM authentication
• fuzzing capability for resources that are referenced by URL parameter
• ability to send traffic through a proxy
• an informative scan status screen
• report generation (text files)
  
• automatic update feature

For being so polished, DirBuster has some quizzical misspellings. Another small quibble is that the tool's "advanced options" are not saved after you close it down. The author told me there is a new version in the works, and both of these issues will be addressed.

IE Developer Toolbar Incompatible with HttpOnly Cookies

Today I discovered that the Microsoft Internet Explorer Developer Toolbar is not able to "see" cookies marked as HttpOnly. This is illustrated in the figures below.
Essentially, this behavior tells me that the tool accesses the cookies using JavaScript (or client-side script of some sort). Since Microsoft originated the concept of HttpOnly, you would think their tool would be able to handle it. Unfortunately, it does not, and I'm running the latest version (1.00.2188.0).

The Firefox Web Developer Toolbar, a great extension created by Chris Pederick, suffers from no such problems. Below are some screen shots to illustrate. Although it wasn't created for web application security professionals, it is an unbelievably useful tool and I highly recommend it. I often use it during application assessments to manipulate cookies, inspect forms, view all JavaScript, switch form actions from POSTs to GETs, and much more.