tag:blogger.com,1999:blog-9059333297663038564.post4531309359358134913..comments2023-04-26T03:41:08.158-07:00Comments on Realeyes Technology: Database SecurityJim Sansinghttp://www.blogger.com/profile/10880439153185950336noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-9059333297663038564.post-16567800356438289062010-04-27T22:49:19.049-07:002010-04-27T22:49:19.049-07:00Jim Sansing,
Thanks for sharing the informative ar...Jim Sansing,<br />Thanks for sharing the informative article,it is very helpful,Database security is one of the important aspect of the computer security as databases hold vital and crucial data of the world such as banking detail, company’s data, and so on. Most of the websites and applications which we use are vulnerable to malwares, infectious code, etc. Buffer overflow and SQL injection are the most concerned things in security as most of the old applications and databases are vulnerable where there are millions of them could be affected. <br /><br />for more information check this link:http://www.eccouncil.org/certification/certified_ethical_hacker.aspxSmithhttps://www.blogger.com/profile/04178379802038260500noreply@blogger.comtag:blogger.com,1999:blog-9059333297663038564.post-53665391941520642292009-03-19T10:09:00.000-07:002009-03-19T10:09:00.000-07:00@Eric,I stand corrected (see the update in the ori...@Eric,<BR/><BR/>I stand corrected (see the update in the original post). I do not believe that the way it works is 'elegant'. It simply treats the SQL injection attempt as data, so my data now has 'select foo from foobar' in the middle of it. But that is far better than nothing.<BR/><BR/>Regarding your 2nd comment, I count parsing for context as security, and I do not expect the database interface to have any understanding of this. For example, a ports field should be tested for the range 0 - 65,535 so that when the data is used, it does not cause errors which could result in down time or worse. I believe this is similar to the points that Ken and Rogan made.<BR/><BR/>Later . . . JimJim Sansinghttps://www.blogger.com/profile/10880439153185950336noreply@blogger.comtag:blogger.com,1999:blog-9059333297663038564.post-38626316172414818142009-03-19T01:01:00.000-07:002009-03-19T01:01:00.000-07:00Ken,Of course you should be validating the input f...Ken,<BR/><BR/>Of course you should be validating the input for other types of attacks. But this is not the job of the java.sql package.<BR/><BR/>java.sql provides the PreparedStatement (of which the OP was clearly not aware), which is *the* correct solution for getting untrusted data into and out of a database (along with CallableStatement for stored procedures), and obviates the need to explain whether to use '' or \', etc to escape quotes, as all that is taken care of by the DB-specific java.sql.Driver implementation.<BR/><BR/>Checking for things like XSS and other malicious input is either app specific or at least app-TYPE specific, and does not belong in the java.sql package.Rogan Daweshttps://www.blogger.com/profile/01542072237124664034noreply@blogger.comtag:blogger.com,1999:blog-9059333297663038564.post-42153247800942412992009-03-18T22:57:00.000-07:002009-03-18T22:57:00.000-07:00Just because you're using parameterized queries do...Just because you're using parameterized queries doesn't mean you shouldn't do security parsing of the input.<BR/><BR/>Parameterized queries indeed take SQL injection out of play, but unvalidated input can still carry other poisonous data, such as cross-site scripting and many many others.<BR/><BR/>It's still (and always, IMHO) a good idea to do positive input validation, even if you're doing parameterized queries.<BR/><BR/>Note, you should still do parameterized queries, of course. Just don't expect this to relieve you of the burden of input validation!<BR/><BR/>Cheers,<BR/><BR/>Ken van WykKRvWhttps://www.blogger.com/profile/16052574543487490732noreply@blogger.comtag:blogger.com,1999:blog-9059333297663038564.post-50159733883796186612009-03-18T19:17:00.000-07:002009-03-18T19:17:00.000-07:00Sorry for the double post...If you use the paramet...Sorry for the double post...<BR/><BR/>If you use the parameterized queries, and they eliminate the possibility of SQL injection, what is the point of doing "security" parsing at all?<BR/><BR/>Also, there are benefits to doing queries in this method as well, in many database platforms, it will speed up your application, because the SQL statement being executed is probably run many times over, and therefore can benefit from the query cache implemented by many RDBMs.<BR/><BR/>Ok, Rant over...Eric Kerinhttps://www.blogger.com/profile/08714287165212427135noreply@blogger.comtag:blogger.com,1999:blog-9059333297663038564.post-83774806930406033172009-03-18T19:14:00.000-07:002009-03-18T19:14:00.000-07:00In the specific case of JDBC, please research the ...In the specific case of JDBC, please research the java.sql.PreparedStatement class. <BR/>It allows you to define place holders for where data should go, and the JDBC libraries ALL handle making sure the data passed to the setString, setInt,etc methods are <B>only</B> interpreted as data (If they do not do this, the specific JDBC driver is very broken) This method makes SQL injection impossible, with no extra escaping or validation needed by the application programmer.<BR/><BR/>Every major language/environment that does database access has a similar method I've personally done it in JAVA, .NET, PHP and Perl, but this design pattern has existed for many years, and is prevalent in any platform that does database access.Eric Kerinhttps://www.blogger.com/profile/08714287165212427135noreply@blogger.com