<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Kommentare zu: Best (insecure) Practice PL/SQL on OTN</title>
	<link>http://blog.red-database-security.com/2007/07/31/best-insecure-practice-plsql-on-otn/</link>
	<description></description>
	<pubDate>Sat, 22 Nov 2008 07:54:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.1</generator>

	<item>
		<title>Von: Steven Feuerstein</title>
		<link>http://blog.red-database-security.com/2007/07/31/best-insecure-practice-plsql-on-otn/#comment-667</link>
		<author>Steven Feuerstein</author>
		<pubDate>Sat, 01 Sep 2007 08:06:50 +0000</pubDate>
		<guid>http://blog.red-database-security.com/2007/07/31/best-insecure-practice-plsql-on-otn/#comment-667</guid>
		<description>Alexander,

Thanks so much for raising this concern about the code example. It does, indeed, contain a SQL injection vulnerability. I believe that it would actually be quite difficult to "bullet proof" this piece of code, given the generality of its desired functionality. I also expect that if anyone actually used it, its usage would be buried so deep inside an application that the possibility of external, malicious inputs to the program would be minuscule. 

Minuscule is not, however, good enough when a person is sufficiently (and rightly) concerned about the security of their system.

Rather than come up with a new implementation of this program which would be secure from SQL injection, I have decided to remove the code sample from the OTN page.

Congratulations for making the Oracle PL/SQL world just a tiny bit safer for everyone!

Steven Feuerstein</description>
		<content:encoded><![CDATA[<p>Alexander,</p>
<p>Thanks so much for raising this concern about the code example. It does, indeed, contain a SQL injection vulnerability. I believe that it would actually be quite difficult to &#8220;bullet proof&#8221; this piece of code, given the generality of its desired functionality. I also expect that if anyone actually used it, its usage would be buried so deep inside an application that the possibility of external, malicious inputs to the program would be minuscule. </p>
<p>Minuscule is not, however, good enough when a person is sufficiently (and rightly) concerned about the security of their system.</p>
<p>Rather than come up with a new implementation of this program which would be secure from SQL injection, I have decided to remove the code sample from the OTN page.</p>
<p>Congratulations for making the Oracle PL/SQL world just a tiny bit safer for everyone!</p>
<p>Steven Feuerstein</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Alexander Kornbrust</title>
		<link>http://blog.red-database-security.com/2007/07/31/best-insecure-practice-plsql-on-otn/#comment-99</link>
		<author>Alexander Kornbrust</author>
		<pubDate>Wed, 01 Aug 2007 08:10:08 +0000</pubDate>
		<guid>http://blog.red-database-security.com/2007/07/31/best-insecure-practice-plsql-on-otn/#comment-99</guid>
		<description>Patrick

it's true that the secure version would be much better. 

But I have only limited resources and for a secure version it is necessary to understand the code completely which can take some time. It's typical for a source code audit to find vulnerable code but not to provide fixes. The developers are responsible for fixing the problems.

In the case of the package str2list you should restrict the parameter showproc or pkg, e.g. allowing only some special values (e.g. if pkg not in ('MYPACK1','MYPACK2','ORDER').


Alex</description>
		<content:encoded><![CDATA[<p>Patrick</p>
<p>it&#8217;s true that the secure version would be much better. </p>
<p>But I have only limited resources and for a secure version it is necessary to understand the code completely which can take some time. It&#8217;s typical for a source code audit to find vulnerable code but not to provide fixes. The developers are responsible for fixing the problems.</p>
<p>In the case of the package str2list you should restrict the parameter showproc or pkg, e.g. allowing only some special values (e.g. if pkg not in (&#8217;MYPACK1&#8242;,&#8217;MYPACK2&#8242;,&#8217;ORDER&#8217;).</p>
<p>Alex</p>
]]></content:encoded>
	</item>
	<item>
		<title>Von: Patrick Wolf</title>
		<link>http://blog.red-database-security.com/2007/07/31/best-insecure-practice-plsql-on-otn/#comment-96</link>
		<author>Patrick Wolf</author>
		<pubDate>Wed, 01 Aug 2007 07:35:33 +0000</pubDate>
		<guid>http://blog.red-database-security.com/2007/07/31/best-insecure-practice-plsql-on-otn/#comment-96</guid>
		<description>Just pointing on someone else code and say it's not secure is also just the half side of the truth. It would be much better to show the secure version, so that we can learn how it should look like and how we should write our code.

Thanks
Patrick</description>
		<content:encoded><![CDATA[<p>Just pointing on someone else code and say it&#8217;s not secure is also just the half side of the truth. It would be much better to show the secure version, so that we can learn how it should look like and how we should write our code.</p>
<p>Thanks<br />
Patrick</p>
]]></content:encoded>
	</item>
</channel>
</rss>
