I am concerned with security myself, too, a lot, in fact. And I, too, have a hard time selling it to the big shots of my company. Although contrary to you I found that already the first hint at immense costs that can be saved helps (That I save myself a lot of repair work as well doesn't seem to phase them at all... oh well.)

When your bosses are so non-insightful (is that insightless?) that they won't even agree to a demo, and you're leaving the company anyway, I'd say, let it pass. If nothing happens, they've got more luck than they deserve - not very probable. If something happens, they don't deserve better, it's none of your concern anymore, and they might (!) realise that you were right.

Note: I am aware that what I'm saying here is bad practice. Evil. I would not normally do this, ever! Even deliberately crashing your system for demonstration purposes sends shivers down my spine. Letting your security slide like this cannot be anything else than the ultimate measure!

Update: Having submitted this, I realised that this is actually my 50th post. Whoheee! :)

--cs

There are nights when the wolves are silent and only the moon howls. - George Carlin

thanks :) there's a lot of very insightful posts here, and all very nice. And i'll be following the main advice, that is : don't take it too personal, you're leaving anyway ;] !! yes, i shouldn't really care for them anymore now - just, as you adviced me, make clear that this is not MY decision to lower security. It's just that i felt like i failed - it was important to me to sensibilize my co-workers to security, and i didn't manage to.
Anyway, i had a gooooood interview today and the company i'm targetting has a strong, skilled security department :). I won't have this kind of trouble anymore, then, hopefully ! (but loaaads of new problems, hopefully too, else i might get bored ;] !)

I think you either misunderstood the point that was being made ("never trust the client") or misstated what happened in your original post. You wrote:

The client i wrote was filtering inputs and was making sure that only the expected parameters were sent to the server.

As was stated earlier, you can't rely on the client to filter the inputs, so putting the filtering code back into the client won't solve the problem. The filtering needs to happen on the server. Otherwise, there's nothing to keep someone from writing their own client program to send whatever data to the server.

Also, the most damaging attack (in my opinion) is not one that destroys or obviously corrupts the data. That type of attack is noticed quickly and the data is soon restored from a backup. The most damaging attack is one that modifies the data in small ways: swapping the address of one company with that of another, randomly modifying balances, randomly creating bogus debits/credits, etc. By the time people notice something is wrong (such as when incorrect bills are sent to the wrong companies), you're faced with spending a huge amount of time fixing it. That means tracking down when the problems began, then either restoring the database from just before that point (which might mean blowing away nearly a month's worth of input) or examining each record to determine what is correct and what is not. Not to mention the hit to the company's reputation if they've sent Company A's bill to Company B.

you're right. But i wanted to make it short, actually my "client" is a middleware (it intercepts requests from the client and (was filtering them and) forwards them to the server - actually, to a servlet). Data used to be filtered in the servlet, but as this "was slowering down the backend" (sic!) this had been removed, and put in some other object, deep in the code, and the "filtering" is done very late, and only on missing params - not on potentially harmfull chars. That's why i felt like *some* filtering had to be done, maybe not in the right place.
And about the most damaging attack, i totally agree with you.