I had some fun, fun times attempting to address a wide variety of security issues in code from a partner company at, well, let's call them a popular outsourcing destination. It involved, at one point, having to explain to my management why their least senior engineer needed the webcasting room so that he could explain XSS to the ISO-certified 20+ years of experience blah blah blah project leads over there. "This is not Severity: Cosmetic. It lets anyone expose our corporation to End Of The World Nightmare PR, because they get to [predictable consequence of compromise of system, punchline is 'people die']." "But only if they find out about it, right?"
This came up in our engineering ethics class in college. Suppose you said "No, that is unethical / professional irresponsible / etc." or its effective-but-weasley younger brother "Please document that request in writing."?
Submit an exploit anonymously somewhere where it will get published. Obviously, don't indicate that you're an employee. A big benefit of full disclosure is that it doesn't allow companies to sit around and ignore security problems without facing serious liability risks at the very least.
I've never used any library to communicate with a database that made safe code harder to write than unsafe code, so I don't see how this will be an issue.
Reading the article, I was wondering if the story was going to take a turn in that direction. Luckily, it seems that ICIC handled the issue pretty well.
> Although there are better ways to accomplish what you need to do, the immediate way to fix this is to validate the errmsg parameter to make sure it only contains safe values. This means that there should be no <, > &, " or ' characters in this parameter.
No! XSS is an encoding failure. Don't try to solve it with sanitization. That leads to silly situations like users named O'Malley getting errors because you don't allow quotes in names.
Sanitization is for controlling the structure of data, like making sure names aren't a million characters long, or making sure all orders have at least one order line. It prevents situations that shouldn't be possible, that aren't sane. Get it?
"Encoding" means representing data in different ways, for instance so it can be stored/transported in a stream.
One of my clients is a Bank. I work occasionally on one of their intranet-sites-that's-actually-not-on-the-intranet-but-the-internet, and it has a password recovery procedure written in plain text on the login screen and open to the most basic social engineering imaginable [Have to be careful what I say here. I'd love to describe just how easy it is, but I'd better not]
I've spoken to them and told them this is A Very Bad Thing, but they just brushed me off, so I wrote a pretty strongly worded email outlining how and why it was bad, but they just said [paraphrasing] "That's our procedure. people forget passwords all the time and we need to make it easy or they'll get upset"
The people in charge honestly seem to have no idea that people from outside the company can see this site. I try and try, but now I just despair
In that case, and based on their brush off, don't deal with IT. Send your concerns to the Internal Auditing department. They (usually) have the stroke to make people sit down and take things seriously. Internal Auditing is the ones who have to interface with federal regulators, and possibly with the SEC.
Incidentally, I work at a bank, and to get access remotely you have to have a randomly-generated username, a random password, and a client-side certificate. The VPN software denies all outgoing connections except to port 80 (and the VPN port, I guess) when it is not active. When it is active, it makes all the network interfaces that aren't the VPN disappear (so you can't see your link-level network anymore). Then, it asks for your password every 24 hours.
Usually I find the commute to work less stressful.
But it does show you that some organizations do take data security seriously... perhaps too seriously. (The port blocking is just security theater. I can run whatever I want over port 80. But the random username / random password / client-side SSL certificate is excellent security.)
But the random username / random password / client-side SSL certificate is excellent security.
The SSL certificate is, but not the random username. That's just a maintenance hassle. A username is not a secret - that's what the password is for. The random password isn't so great, either, because it pretty much forces you to write it down and then it just becomes a (poor) version of the SSL certificate. It should instead be a strong password that you can actually remember.
It should instead be a strong password that you can actually remember.
I agree that in theory a strong password one can remember is more secure than a randomly generated password that you have to write down.
However in practice, people just choose easy to guess passwords, or reuse the same password everywhere. That's a larger security problem, so the random passwords are more secure in practice.
I've been using an extranet site recently that calls you, using Twilio or something I guess. They have my mobile phone number.
You enter your username and password on the web form and your phone rings a couple of seconds later. You are asked by a recording to type in your PIN. When you do, the HTTP request is completed and you are logged in.
It's very easy as a user, and seems quite secure. The username/password/PIN are all quite weak and easy to remember, but in conjunction with the phone call, it's fairly strong.
What do you mean by not seeing the link level anymore? What happens if you connect your vpn through a virtual machine? Will the host still have normal internet?
I wouldn't be too quick to criticize ICICI on their fix. They did the right thing -- the quickest possible secure fix. Yes, input filtering is the "most right" fix, but speed is even more important in cases like this. It's quite likely that switching to a boolean significantly reduced the number of side effects. If they don't switch on input filtering in January some time, then we can start criticizing.
That was a very, very long 2.5 years.