tag:blogger.com,1999:blog-414482498098790205.post6532943071250774752..comments2023-05-18T03:46:07.779-06:00Comments on Questioning Software: I'm a user and I just did thatBen Simohttp://www.blogger.com/profile/11448600123169359955noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-414482498098790205.post-85224828286091975082007-09-11T02:59:00.000-06:002007-09-11T02:59:00.000-06:00Hi,This blog is very good and informative.Ecommerc...Hi,<BR/><BR/>This blog is very good and informative.<BR/><A HREF="http://www.frontlinesoft.com" REL="nofollow">Ecommerce Solutions</A><BR/><A HREF="http://www.processfront.com" REL="nofollow">Free Directory</A><BR/><BR/>khanAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-414482498098790205.post-17262234638306796662007-07-07T16:20:00.000-06:002007-07-07T16:20:00.000-06:00@Alan,Some organizations mature better than others...@Alan,<BR/><BR/>Some organizations mature better than others. I don't see any reduction over the past ten years in the frequency of these conversations; but I do see that it is often easier to get bugs fixed by bringing up the security implications. People seem to understand security risks once they are explained.<BR/><BR/>These types of bugs are exactly what become security holes that allow unfriendly users to do things that impact business operations. Sometimes, these things can also be triggered by friendly users doing what they were not expected to do. I agree that anyone in software development these days should be aware of the security risks. The truth is that too many people don't seem to think of security and put on their "functional" development and testing blinders. Applications need to do what the functional requirements require AND they need to not do what they should not do.<BR/><BR/>I remember testing a system many years ago that had a flaw in its search functionality. It was possible for a user to "crash" the server by performing a search that returned "too many" documents. Instead of fixing the bug, users of this internal application were instructed to not perform searches that returned more than a number of results that was determined to be safe. These SME uses were likely to have a better idea of how many results may be returned than I as a tester. However, it was silly to expect users to always know what results would be expected; and it was foolish to expect all users (even internal users) to behave in a friendly manner. <BR/><BR/>Let's see... Joe is late on completing his document edits. To create an excuse for not meeting his deadlines, he knows that he can perform a search that will take the system down. That should give him some time to get caught up and then paste his new data into the system after it has been restarted. The problem is that if this unscrupulous Joe were to follow through with such a plan, he could impact other important work and data. And that's just an example of selfish ambition; not malicious action against the company or others.<BR/><BR/>This problem was eventually fixed after some "important people" encountered the "limitation".Ben Simohttps://www.blogger.com/profile/11448600123169359955noreply@blogger.comtag:blogger.com,1999:blog-414482498098790205.post-84486530067700941112007-07-06T23:46:00.000-06:002007-07-06T23:46:00.000-06:00Ben,This is so familiar. About 20-25 years ago, wh...Ben,<BR/>This is so familiar. About 20-25 years ago, when I worked at IBM Santa Teresa Lab (now renamed to Silicon Valley Lab), my friend and colleague Mike Golding always used to send me his latest programmer tools to try out. <BR/><BR/>Now I am pretty sure that anyone who knows Mike (now retired from IBM) would agree that he is a very good programmer. But since I usually had very little idea of his tool's intended use, I would usually crash his code after entering a few random responses.<BR/><BR/>Naturally, Mike would then protest that "you're not supposed to do that." But he never complained, and always sent me his latest code with the expectation that -- as a dumb user -- I would uncover bugs that he could not even imagine.<BR/><BR/>Maybe that attitude is what separates a good developer from a great one, because I have no doubt that Mike Golding was one of IBM's most talented developers.cloosleyhttps://www.blogger.com/profile/12480271885833781496noreply@blogger.comtag:blogger.com,1999:blog-414482498098790205.post-46949578603141618302007-07-06T19:56:00.000-06:002007-07-06T19:56:00.000-06:00Sometimes I feel like I'm in a timewarp. Bolton's ...Sometimes I feel like I'm in a timewarp. Bolton's conversation is something I heard often ten years ago, but rarely - if ever - today. I am sorry (and embarrassed for the profession) that this is still the case.<BR/>It doesn't matter if a user would never do that - too many of these types of bugs end up as exploits or DOS attacks for this argument to <I>ever</I> hold up.Anonymousnoreply@blogger.com