|
Comments do work in other scripting languages as well; both Cold Fusion and Net.Data support the -- syntax. Almost any page that does not "sanity check" data incoming from a browser; whether entered by the user or not, is probably vulnerable; no matter what other precautions have been taken. This does not; however, reduce the effectiveness of other precautions (like reducing privileges of the account running the webserver, using prepared statements, or using stored procedures to access data) as the seriousness of an intrusion can be greatly reduced. SQL injection is as big of a danger to a machine running OS/400 as a machine running Windows NT 4.0 Service Pack 1 (don't try that at home). The application code is what determines the level of vulnerability to this particular attack. Of course this is only one vulnerability - OS/400 has no IIS vulnerabilities. I do agree that poor programming in the language of choice is at fault; but I think you would be surprised a how prevalent examples of this vulnerability are. Additionally it is not confined to machines running asp or with a particular authentication scheme nor do most monitoring tools provide any indication that you have been "hacked" as long as no damage is done. -----Original Message----- From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx] Sent: Wednesday, February 04, 2004 2:38 PM To: 'Midrange Systems Technical Discussion' Subject: RE: SQL Injection - security risk or bad programming? > From: Walden H. Leverich III > > the problem of SQL Injection exists regardless of the authentication > method used or even the existence of authentication. Only in poorly written code. > To say that the problem is due to "really bad ASP programming" is just > inflammatory. > There's nothing in this issue that's Microsoft's fault, don't pin it > there. Walden, I went out of my way to be non-inflammatory, but since you think I wasn't trying hard enough, let me expand on my point and remind of what it looks like when I do voice my opinion <grin>. Whether you want to admit it or not, this is really bad ASP programming, particularly the bit about the "--" hack in the SQL statement, which to my knowledge doesn't work on any other platform. And while a version of this technique can probably be used in a really crappy JDBC statement, the truth is that most good Java programmers don't do that sort of stuff anymore, especially since JDBC 2. In fact, I have an entire lab available at Rochester Initiative on using JDBC 2 properly. But here's the part where I really blame Microsoft: The statement "many programmers don't use them" is in reference to prepared statements but could just as well include any good programming techniques. A lot of commercial programming today stinks, and it is mostly a matter of bad training and bad management. Any programmer who uses obviously flawed programming techniques needs more training, any manager who allows them to be used in production software should be fired. If we stopped making excuses for bad programming and returned to an environment where quality was both expected and required then we wouldn't have most of these hacks. For example, all buffer overrun hacks are a direct result of a REALLY BAD PROGRAMMING TECHNIQUE. In fact, it's the same bad programming technique: not checking for the end of the buffer (D'oh!). But since this level of quality is accepted in the software that comes out of Redmond, it is now pervasive in the computing community. Maybe it's not Microsoft's fault in this particular case, but the atmosphere of poor quality programming I lay squarely at the feet of the folks in Redmond. By putting out code using lazy and sloppy techniques, Microsoft invented the email virus. By refusing to fix it except with more hacks upon hacks, they extend the life of the concept. Or more precisely, they continue to provide the host where these things could thrive. If you think your network as a human body, Windows is the HIV of desktop computing. And it's bad enough that it's on your desktop; it's even scarier when it's considered for mission critical business operations. There, NOW you can accuse me of being inflammatory <smile>. Joe _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.