a/ Original error message specifically included hypens, and apostrophes, and for that matter "/" used in many addresses. So I think you're extending the argument here to some notion of an extended set of "system boundaries" which could be anything. Of course, with such a wide scope I'm sure you could come up with something that won't agree with any manner of input. For example, piping a raw executable over a socket to a server expecting HTTP won't go down so well.
The original post was about a certain class of ASCII characters into a feedback form, however, and the original list contained some characters which you're going to see in the set of characters likely to be entered into a feedback form. "Hi, I'm Fred." for example violates their security requirements. If that was a real security concern their internal systems would fall over on every-day customer data, which IS quite ridiculous. b/ I didn't see Unicode in the original post, your point is true in general but isn't in the scope of the OP's post. c/ The input should be copied to a back-end store as entered. The individual GUIs should be written to escape correctly whatever they are about to display. I don't see it as a huge problem to expect that people wrote their systems yesterday, and write their systems today to cope with that. (ie: Whether it's a VT-100, OS/2, Windows, or HTML based system, is it really so hard to expect that developers correctly encoded information for display?) On Wed, Oct 27, 2010 at 2:59 PM, Ken Schaefer <[email protected]> wrote: > I’m sure systems can cope – but there are a number of challenges: > > a) System boundaries: what one system finds acceptable may not be > acceptable to another (apostrophes I’m sure we’re all well aware of) > > b) Unicode is probably something that older systems can’t cope with > > c) It wasn’t that long ago that SQL injection and XSS become hot > topics – what about older GUIs written many years ago that are used by > branch staff or call centre staff. Would they be able to cope? > > > > Whilst it may be poor coding, the effort required to fix the problem is > immense. So saying “in this day and age I expect x” is a bit nonsensical. > What’s so special about writing code today that makes effort required to > remediate enterprise systems just go away? Or that makes today’s code able > to handle the challenges of the next 10-20 years? Nothing as far as I’m > aware. > > > > Cheers > > Ken > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Paul Gaske > *Sent:* Wednesday, 27 October 2010 12:29 PM > *To:* ozDotNet > *Subject:* Re: Rant > > > > Oh; I dunno. I'm thinking you're right to jump up and down. Especially if > you've got an apostrophe in your name or a hyphenated last name. > Congratulations, you're now a security risk! > > > > Seems like a bit of a fail to me. I'm sure banking systems, no matter how > long ago written, would be able to handle hyphens or apostrophes. This > really does sound like poor coding to me. > > > > Cheers, > > Paul. > > On Wed, Oct 27, 2010 at 2:25 PM, Stephen Price <[email protected]> > wrote: > > It's very easy to jump up and down about this sort of stuff when it > doesn't work. Your email has made me pause and think about it, and > let's be honest, this coding stuff we do is complicated. So many > variable (pardon the pun), so much can go wrong. It doesn't always > work as intended. If it was easy then everyone would be doing it. > > I know I strive to better my coding skills continually, and even after > years of coding I know there will still be bugs in my code. I don't > trust my own code (possibly a good trait, apparently) and use unit > tests etc to help improve the code quality. > > It wasn't so long ago that you had to physically walk into a bank to > do your banking. It's become mainstream so fast. I can see how you > would jump up and down about a user having to enter their data > correctly, but I guess there has to be some validation. Is there a > feedback section that would allow you to let them know so they can add > it to their "to be fixed" backlog? If you don't let them know (and no > one else does) then you get what you put up with. I often send emails > or feedback to companies when I find issues with things. It doesn't > always make it to the right person but at least I tried. > > cheers, > Stephen > > > On Wed, Oct 27, 2010 at 12:10 PM, Ken Schaefer <[email protected]> > wrote: > > Hi, > > > > > > > > Just because a UI is now in neat HTML doesn’t mean that every backend > > system, and every other system used to access this data, can cope. > > > > > > > > I worked on Westpac’s IB upgrade project (the monitoring part) and it’s a > > huge amount of work just to upgrade one small part of it. > > > > > > > > Cheers > > > > Ken > > > > > > > > From: [email protected] [mailto: > [email protected]] > > On Behalf Of [email protected] > > Sent: Wednesday, 27 October 2010 9:21 AM > > To: [email protected] > > Subject: OT: Rant > > > > > > > > <Rant> > > I just ran into the following text on the Westpac Altitude Rewards web > site. > > I am amazed that in this day and age that the developers and/or designers > > for a banking-related web site have just *given up* and are forcing their > > customers to clean their data. > > > > Note that if your message does include any of the characters you get an > > 'input error' feedback but you still have to find the offending > characters > > and clean it yourself. Unbelievable! > > > > </Rant> > > > -- Paul Gaske ([email protected]) Software Engineer Codify Pty Ltd - www.codify.com Phone: +61 (7) 3210 6268 | Facsimile: +61 (7) 3210 6269 | Mobile: +61 417 026 666 Address Info: http://www.codify.com/AboutUs/ContactDetails
