When simply filtering request parameters is not enough or about the dangers of universality

The esteemed company “Russian Railways” has a wonderful website ticket.rzd.ru . Despite some rough edges, the site copes well with its main task - it allows you to order and pay for tickets online.

For some time I ordered tickets for myself there, and my research entity could not just pass by without looking at the source code of the page.


')
At the end of the order procedure, when everything has been paid for, the order page is displayed, allowing you to print out the form, among other things, containing the barcode with the order number.



The address of this image looks like this:
https://ticket.rzd.ru/isvp/barcode?data=0000000000000&type=Code39&width=1&height=60&checksum=false .
The first thing I did was set up my own arbitrary number in the data field. The result is predictable - I received a barcode for this number. Well, we have a wonderful free universal barcode coding service. But is it good for RJ? Dig further ...

Then I cleared the data field. The result is a stack-trace with the name of the barcode generator library ( barbecue ) and the application server ( IBM WebSphere Application Server ). How much information did it give? This, of course, is not enough to break the server. But to show your "passport" to an outsider "person on the street" is not the most reasonable thing.

Let's try to look at the other parameters:

• type = Code39 - This is a bar code coding type . We are interested in a little.
• width = 1 - at random we find out that this is the width of the lines.
• height = 60 - obviously height.
• checksum = false - obviously, adding additional checksum bars.

Now, in principle, the attack vector is already ready. "Drawing" a bar code, obviously occurs in memory, and then is given to the requester. The parameters of the width and height of the lines, the length of the digital code is not filtered in any way - therefore, by a trivial search, the parameters that eat up all the server's RAM by a dozen or so requests are selected. Until they figure it out, what's the matter - a few hours "in the down". And if the OS settings are incorrect, and it starts swapping, it is not far from the hardware death of the server.

For obvious reasons, I do not give the finished “death links”. And I hope for the prudence of the reader who did not check that this is true, and who believed the word.

Let us leave for the time being the question to whom and why this may need to be done by the Russian Railways. This is a good example to us that:

1. You need to filter the parameters not only in PHP, but also in completely “harmless” Java services;
2. to make unnecessarily universal services is harmful.

PS A letter to the developers of the site was sent in advance. A polite answer about what they "take into account" came (here respect), but the time goes on, and until they "consider" (here it is disrespect) ...