One of the purposes of this blog was the battle of better software quality in our everyday lives.
Polish government websites in the past tend to be famous for their lack of testing and missing the standard quality levels, but it was in the past. After several years form debut such amazing pieces of software as PKP or ZUS sites, I naively thought that the situation got better.
Alarmed by the article stating that every taxpayer in Poland should generate their own bank number to be able to pay taxes next year , I decided to go to the government website https://www.podatki.gov.pl and generate it for myself.
Such a brilliant occasion for testing! #NeverStopTesting
The idea of the bank account number generation is that you enter your PESEL number (the unique number, that every polish citizen has).
The PESEL is an 11-digit number, containing one’s date of birth.
What you are supposed to do in order to follow the instructions:
- Open the website https://www.podatki.gov.pl/generator-mikrorachunku-podatkowego/
- Select PESEL
- Type your PESEL number
Expected result: Account number is generated.
nice and smooth. Worked for me. 🙂
…. and what you are supposed to do when you are a tester 😀
“A Software Tester walks into a bar….”
One of my testing scenarios:
- Enter curl …
for example: curl https://www.podatki.gov.pl/umbraco/surface/TaxAccountNumberSearch/GetAccountNumberByPesel?pesel=9223372036854775807
- Click Enter
What does it mean? The UI of this website, as i tested, was protected from entering -, a, 8946180480104610401 or anything else into input field. good job! On the other hand, the Backed…..
Well, above error speaks for itself. But I decided to explain it in a bit more detailed way:
- There is no data validation on the backed side
- Unnecessary information displayed in public
=> in the error’s stack trace
- The code has been compiled in the debug version (including all information about the source code – you can see it in the file names and rows in the stack trace) deployed in production
=> unnecessary leak of information plus worse performance of the site. The code in debug version is usually not optimized and has additional instructions
- It is likely that the code has been compiled of the developer’s machine and deployed in production (Mr. Jedrzej Lenart?)
=> it is a violation of security rules – you have no guarantee that the local changes has not been pushed into production as well
- The website calls this web-service by
POST(which is correct), but in the browser and in curl you can see that the parameter “
pesel"is called by
GET(in the URL)
=> it is not the worst solution, but it usually makes the website more prone to CSFR attacks and the PESEL number is visible in: logs of servers and routers – even when the communication is encrypted (URLs are not encrypted).
It seems that someone in the ministry of Finance IT department deploys code without testing. Bravo for Agile!
Bravo for Continuous Delivery!
On the other hand, someone deploys code on GOVERMENT website without testing. Code prone for attack.
It is possible that they were not aware of the micro-service working below, but still…
When I posted that on Twitter it took couple of minutes in the Ministry of Finance for displaying good 500:
So Agile again!
Just wanted to share it with you, because Mr. Jędrzej made my day. (info in the screenshot).
In case of any comments stalk me on Twitter. Cheers!