Attention ShiftSync community! We are excited to announce a brand new testing challenge prepared exclusively for you by the renowned expert, James Bach. The purpose of this challenge is to provide you with a way to showcase your analytical testing skills for other people to review and evaluate. You will get a winner badge and a certificate of achievement.ย
Voting goes by likes. Like answers, which in your opinion provide the best solution to the challenge. The replies with the greatest number of likes will get winner badges.
Voting will be closed on 24.07.2023. However, even after the deadline, you may submit your solution in the comments and receive points.
ย
Chapter
Here is a parking cost calculator for an airport: https://developsense.com/parkcalc/index.php (This was copied from a real airport website, some years ago.)
There is a rumor that, because of poor input validation, you can make this calculator show huge parking costs (into the billions of dollars). Try to reproduce that. What is the highest amount you can make it quote you for parking?
Protocol
This is a hard problem meant to challenge you. There is no fixed time limit for solving it.
Use any resource you like to solve this problem. Tackling this with a team of people tends to work well.
Deliverable
Please explain your process in the comment section.
Take screenshots of your most interesting and extreme results and attach them to your comment.
ย
About James Bach: ย
James Bach@satisficeย is a highly influential figure in software testing, renowned for his pioneering work on exploratory testing. His book, "Lessons Learned in Software Testing," co-authored with Cem Kaner and Bret Pettichord, is a go-to resource for testers worldwide. Bach emphasizes the value of skilled testing and encourages critical thinking, challenging traditional approaches. With his unwavering dedication, Bach has reshaped testing standards and inspired countless testers to think outside the box.
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.
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.
Having an adequate โLeaving Date and Timeโ threshold would really help, e.g. 01/01/2100. Also, please embed the link to the Parking Calc in the โChapterโ section, so that one doesnโt need to copy->paste the link or use โOpen In New Tab OR Windowโ
I interacted around 45ย minutesย with the calculator straight and also during writing this report (around another 45 minutes). Warning: Iโm not used to AM/PM times therefore I might confuse some things which are normal for this.
My currently highest amountย (It might even go higher):ย 5,777,922,043,452.00 ย
Observations:
Dates are not checked for any sanity
A crash when I set the years date to high. The pagesย goes white after some seconds, having no UI anymore.
setting one of theย dates to (-)350,000,000 let the site go white => It would need further investigations to find the exact limit.
ย
Making a successful calculation with Valet Parking resets the option to Short-Term Parking
After a calculation with PM the UI is set back to AM and sometimes is the time also changed:
Warning: Iโm not used to AM/PM times
00:00 PM goes to 12:00 AM
25:99 PM goes to 37:99 AM
Requesting the URL with working values returns the HTML immediately but it does not contains a cost value. With high, working dates takes the response some seconds.
How do I came to this?
At first I played a bit around to learn how this calculator works. What are the UI elements.
My first idea was that day dates in general and specifically extremย years are a fast way to create high amount.
I tried out if dates before 1.1.1970 (Unix date start) where an issue but even for that I could generate costs. Having the Leaving dateย before the Entry date was gave an error message as often as I tried it (maybe in combination with the time can beย found more issues).
Now Iย started playing around with the dates. At first going back in the Entry year likeย 999, -9. With the first -9 I just add 9 to reach the maximum which was -999,999,999 at that time, crashing the site. As I observed with every 9 added the response took longer.
Now I set the Entry date to around -999 and tried in batches to approach the limit.
Maybe I should have stopped pushing the boundaries way earlier. Having Entry dates quite back in the past when no cars makes no sense at all. Also a Leaving date more thanย 100 years in the future is not that different from 1,000 years.
My time is out now. I have to stop the report here. Maybe I can continue and improve this report tomorrow.
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.
the calculator is using simple formula to calculate number of hours of parking and then multiplies it by a unit amount. The unit amount part looked ok to me
Time parked = (End Dateย End time - Start Date Start Time)
There is no validation on End Dateย End time or Start Date Start Time.
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.
@darktelecomย I like your report. Itโs written clearly and seems well-reasoned. I agree that if we are simulating a realistic project situation, you donโt need to go any further. However, sometimes I like to push things beyond the practical on projects because I want to enhance my street cred as a bug investigator/hacker.
