Testing challenge by James Bach 🚀

The sample parking calculator seems to be of an old application/website.

At first sight, it’s UI provides already some tips:

• the OLD UI is a hot tip telling that it may not be responsive; which in fact, it’s not so it’s not going to work well with mobile devices and/or devices with different screen sizes
• there seems to be several input that use the keyboard and also some shortcuts (e.g., for opening a calendar)

Focusing on the input validation, there are at least 2 ways of inputing data: keyboard and mouse. The fact that we can use both may present a challenge in terms of consistence between values edited using either of them.

Besides it, and probably more critical, is the fact that there seems to be no input validation whenever editing the fields using the keyboard; they are just text fields (i.e., “input” elements of “text” type), instead of proper HTML elements that could restrict it to just numbers or even a regular expression.

Knowing this, we can enter some invalid times like:

• 15:00 AM (which is a value out of  bounds)
• 15:00 PM (which becomes 27:00 AM after submitting)
• 25:00 AM (which is a value out of  bounds)
• -25:00 AM (which is a value out of  bounds)

More, 

• the date field doesn’t have a validation, therefore we can enter a date in a whatever format. For example, in some countries it’s common to use YYYY-MM-DD, such as 2023/06/27. If we enter that for the end date, for example,  it will accept it, and returns a cost of more than 1,6 Million USD for a few days.

Additionally, we can see in the browser that submitting the values for calculation performs an HTTP GET, and the parameters can easily be modified on the browser address bar.

We can modify the type of Lot to some unexpected value like STPPP and use that to calculate the parking cost…  which won’t give an error and return $0, such in the following example.

https://developsense.com/parkcalc/index.php?Lot=STPPP&EntryTime=12%3A00&EntryTimeAMPM=AM&EntryDate=6%2F26%2F2023&ExitTime=12%3A00&ExitTimeAMPM=AM&ExitDate=6%2F27%2F2023&action=calculate&Submit=Calculate

More deep testing would be needed but the fact that there are some critical validations that aren’t being done, this parking calculator should not be released and we can even say that probably this needs to be fixed ASAP before more exhaustive testing is performed.

Few descriptions are already provided on top.

The “Choose Leaving Date and Time” field accept real time data, with no restriction on decimal values, in fact it worked till 21 decimal values

result is here

I think I’ll leave out some of the details about the general overview of this calculator (i.e. the UI/UX shortcomings etc.) that have already been addressed here and jump straight into my findings.

First of all, it needs to be noted that the only input validation I’ve found in this calculator is the general check that the entry date shouldn’t be later than the exit date (and vice versa). That’s it. The inputs are not validated for non-digit characters which leaves plenty of room for bugs to crawl in (and hopefully be discovered).

So I started playing with numbers, particularly dates. My initial thought was to set the entry date as early as possible and the exit date as late as possible, hoping that the date difference would end up in a huge cost value returned. That was partially true, and I was able to get to something around a trillion. Adding up nines to the year section led to slower response time, so I decided to switch to time inputs.

It quickly became obvious that the the server did not have any restrictions on seconds part, and the number grew way quicker. 

That’s when I noticed that the number of days actually had scientific notation which was denoted by E+16 part. I wondered, well, if the server returns such a value to the client, then maybe it could process it if the client sends it to the server?
So I immediately tested that out by adding E+199 to the exit time which resulted in something like this…
 

As we can see, the cost number returned was so huge it didn’t even fit the page and broke the layout.
I went further and got curious what would happen if I entered an even bigger number in scientific notation, something around E+99999?
Below is the result

The return value turned out so huge that the calculator returned NAN dollars for infinite number of days.

That’s how far I’ve gone so far. Still wondering if there’s a way to make that thing return a negative value.

It can be difficult to break out of our preconceived ideas of software limitations: for instance, the proper formatting of the date field.

This is what hackers do, though. This is why cybersecurity is so hard. Developers and product owners like to say “no user would do that.” But of course in cybersecurity terms, hackers are users, and they are motivated to find vulnerabilities in our products.

@Sebastian Stautz For project purposes, I agree you don’t need to go any further. Still, it can be a good learning experience to try.

One tool I like to use is Hurl.

Here is the contents of a Hurl file you can use which might make it easier to systematically explore this problem:

GET https://developsense.com/parkcalc/index.php

[QueryStringParams]
Lot: STP
EntryTime: 8:00
EntryTimeAMPM: AM
EntryDate: 6/26/2023
ExitTime: 12:00
ExitTimeAMPM: PM
ExitDate: 6/26/2023
action: calculate
Submit: Calculate

HTTP 200
[Asserts]

xpath "string(/html/body/form/table/tr[4]/td[2])" contains "8.00"

You can keep updating the data and running Hurl. Or you can just add new sections to the file and keep all the history of your attempts.

I have chosen a simple combination of digits like 1 and 9 to check extremities randomly, manipulated the time data only and here is the result.

Why only a combination of 1s and 9s in the date fields?

Well, as a kid, we can think of only 1 and 9 to play with the smallest and largest values excluding 0.

And a wild attempt!

Tests: 

Here are my few random tests and after seeing this kind of profit, I would love to start a business.

1. When all the inputs are in the wrong format.

   

    

2. One Invalid date like 2/38/2100 is no barriers, and we are in profit.

   

    

3.  Even negative signs did not matter!

   

    

4. Following formats but with unexpected values and it works!

   

5. No proper entries but the value of Zeros. Wondering how the calculation logic is working!

   

   Note: I am adding my observations later! Stay tuned.

Please delete this comment if that's the case, but I guess "visiting in quick succession" 😉 this url https://developsense.com/parkcalc/index.php?Lot=STP&EntryTime=12%3A00&EntryTimeAMPM=AM&EntryDate=6%2F26%2F2023&ExitTime=12%3A00&ExitTimeAMPM=AM&ExitDate=6%2F26%2F1.0E%2B304%3A1.0E%2B306&action=calculate&Submit=Calculate

could make that backend sweat a little, huh?

@satisfice ohhh, maybe it was just me, the request hanged for like 30 seconds and got me a blank response

bummer

This was a fun little excercise. At first it was clear that some information is missing to fully test this. What are the supposed prices for every lot? Should I be able to stay for a Year on a Short Term Parking?

But then I though about the real issue I was supposed to investigate and decided to leave those questions for another time.

My first approach was to simply check how much could I adjust the dates. I tried to calculate a 30 year booking. Wich didn’t give me any unreasonable numbers. So I then decided to check if I could book a leaving date before the entry date. To my surprise this seemed to work quite nicely. So then I though about the time. (I also noticed that no error is displayed when the user invents dates like 29th of Febuary 2023)

Something that catched my eye is the AM/PM selector (I was thinking of inputing 24:00 AM). When I clicked the timers, I noticed I was able to write on them. So I started with the obvious 999999999999999999999 and the issue was found.

But I wasn’t done. I thought “Maybe if I am able to go that high I can go way down” so I decided to try with a big negative number “-99999999999999999” seemed reasonable.

Also, robert seems to be a valid date, and quite costly

Here is my report on this nice challenge.

My first goal was to find out how the app behaves with different date format(s) so I’ve tried the following formats: 

• DD/MM/GGGG
• GGGG/MM/DD
• GGGG/DD/MM
• YYYY-MM-DD
• DD-MM-YYYY
• MM-DD-YYYY
• DD.MM.YYYY
• MM.DD.YYYY
• YYYY.MM.DD
• YYYY.DD.MM
• M.D.YYYY
• D.M.YYYY
• YYYY.M.D
• YYYY.D.M
• DD MM YYYY
• MM DD YYYY
• YYYY MM DD
• YYYY DD MM
• D M Y
• D M YYYY
• DD MM 'YY
• DD-MM-YYYY HH:mm:ss
• DD/MM/YYYY HH:mm:ss
• DD.MM.YYYY HH:mm:ss

Next step was to find out how big value can ‘Date’ section accept before breaking and after some experimentation I came to the conclusion that the max/min values are in range, inclusive, -999999999 <> -999999999. 

The next step was to fiddle with the ‘Time’ inputs. There were some interesting finds here too. For example: 

• Start date can be empty and will be set to ‘:00’ after calculation is performed

• If ‘:XX’ is entered in the Leaving time and the ‘PM’ is selected the value will default to ‘12:XX’ after calculation

• Setting start date to 00:00 AM and end date to 99:99 PM. After calculation, the 'end date' is set to '111:99'

• The value in the 'Leaving date' increases with each calculation – 'PM' needs to be selected to achieve this (the pictures below show some of the results have ‘AM’ selected, that is because the picture was taken after the calculation was performed and the form resets some of the values after the calculation)

Then, there were some general issues like: 

• The 'Choose a Lot' resets to 'Short-Term Parking' after each calculation

• Entered values don’t reset after the page reload

Of course, the best one is saved for last. These are the two highest values I’ve managed to obtain (was inspired by results/inputs Shrihari obtained/used):

• $12,708,333,333,333,332,967,401,980,232,859,168,628,525,464,503,698,613,414,522,724,605,015,219,418,325,420,468,736,234,296,598,399,533,039,132,395,113,466,895,373,157,943,356,627,796,442,973,405,410,397,248,800,629,166,261,831,448,178,493,452,611,580,311,562,459,296,227,824,353,005,193,212,658,209,101,865,408,410,243,734,079,892,283,725,736,687,007,252,967,632,114,030,003,305,119,796,382,192,088,645,632.00        (4.2361111111111E+302 Days, 0 Hours, 0 Minutes)

• $24,999,999,999,999,998,481,338,812,638,411,554,650,100,718,050,293,312,382,976,928,928,308,011,407,533,084,757,108,273,143,601,269,371,092,140,295,140,405,431,446,792,984,356,590,076,325,589,497,102,167,206,937,468,253,604,205,027,602,669,275,632,906,102,264,609,299,506,371,378,997,691,599,206,377,054,581,648,872,780,674,019,874,513,365,087,296,656,431,016,019,010,952,114,899,655,187,260,870,345,359,360.00        (8.3333333333333E+302 Days, 2.7720004299093E+288 Hours, 0 Minutes)

I did in the usual format I note down findings when testing (something I learned from RST). One can argue my “improvements” section doesn’t make sense but I seem them as something additional to the current scope. Everybody knows there’s a third party plugin out there somewhere that can do everything this calculator does.

Bugs: 

• The "choose a lot" selection always resets to "Short-term Parking"

  

• It takes negative values as input and also 0 as input

  

• It takes time values greater that 24 as input

  

• There's no way to refresh the thing since every parameter gets embedded in the URL

• AM/PM should be decided based on time value selected. 1300 cannot be an AM value

  

• Time value should auto format from 1200 to 12:00. Regex to detect minutes is missing, it takes the value entered as hours

  

• The only way to get a time value in PM is to enter the AM equivalent, select PM radio button which then adds 12 hours to the value

• If you input a PM value for time and then select the "PM" radio button, it will go beyond 2400

  

• AM/PM radio buttons reset to AM

  

• It even takes text as input for time and date

  

Improvements:

• The date picker should be placed alongside the date field
• The date picker should also include a time picker
• There should be a max time limit to park your car
   

How the date field works

1. No validation of date ranges, invalid date, invalid date format, date combined with strings, and special chars.
2. If you simply enter just numbers (for easy fundamentals- pick anything between 1 to 12), it considers the number as the month like 1 stand for Jan, 2 for Feb, and so on, and calculates the total days of the entry month.

Note: If you select the entry date field with the value 0 and leave date field as 1, it will give you a default value of 31.

3. If you enter the entry date in -/-/- format and 2nd field digit(s) is considered as day only.

The leave date if entered with a number between 1 and 12, is considered as month.

On calculation, the total days are counted as

{total number of the month (from leave date field)- days (from the entry date 2nd field)}

For the below example, total days = (31-12) = 19 days.

4. If you enter both the entry and leave date in -/-/- format.

            On calculation, the total days are counted normally.

5. No matter whatever value you add after -/-/- this, the values are counted based on the values entered within the -/-/- format.

Note: My other few points are already iterated by many of the others.