<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: SQL Injection: Sleeping Giant</title>
	<atom:link href="http://michaeldaw.org/news/sql-injection-sleeping-giant/feed" rel="self" type="application/rss+xml" />
	<link>http://michaeldaw.org/news/sql-injection-sleeping-giant</link>
	<description>Weekly humour</description>
	<lastBuildDate>Thu, 07 May 2009 20:09:50 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Wooshy</title>
		<link>http://michaeldaw.org/news/sql-injection-sleeping-giant/comment-page-1#comment-12658</link>
		<dc:creator>Wooshy</dc:creator>
		<pubDate>Tue, 13 Mar 2007 20:45:32 +0000</pubDate>
		<guid isPermaLink="false">http://michaeldaw.org/news/sql-injection-sleeping-giant/#comment-12658</guid>
		<description>I&#039;d agree with David that won&#039;t take too long to find a XSS vulnerability. The low-hanging fruit here is to look for something that will echo back what you put in. All you need is some HTML knowledge. Release it to bugtraq (usually without telling the script author) and job done. Filtering evasion... That&#039;s part of the challenge. There is a limited set of characters that you want to check to see if it is filter properly or not? (e.g. tags, quotes, apostrophes...)

SQL Injection is not so easy. Generally, you do need to know some SQL before you can start SQL injection and I think that&#039;s the point Dave is trying to make. There&#039;s a lot more attack vectors, you can try once you can put your foot in the door with some blind SQL injection. e.g. attempting to access system tables, selecting data from a table, escalate privileges if possible. That sounds a bit more interesting...</description>
		<content:encoded><![CDATA[<p>I&#8217;d agree with David that won&#8217;t take too long to find a XSS vulnerability. The low-hanging fruit here is to look for something that will echo back what you put in. All you need is some HTML knowledge. Release it to bugtraq (usually without telling the script author) and job done. Filtering evasion&#8230; That&#8217;s part of the challenge. There is a limited set of characters that you want to check to see if it is filter properly or not? (e.g. tags, quotes, apostrophes&#8230;)</p>
<p>SQL Injection is not so easy. Generally, you do need to know some SQL before you can start SQL injection and I think that&#8217;s the point Dave is trying to make. There&#8217;s a lot more attack vectors, you can try once you can put your foot in the door with some blind SQL injection. e.g. attempting to access system tables, selecting data from a table, escalate privileges if possible. That sounds a bit more interesting&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kuza55</title>
		<link>http://michaeldaw.org/news/sql-injection-sleeping-giant/comment-page-1#comment-12068</link>
		<dc:creator>kuza55</dc:creator>
		<pubDate>Fri, 09 Mar 2007 23:45:17 +0000</pubDate>
		<guid isPermaLink="false">http://michaeldaw.org/news/sql-injection-sleeping-giant/#comment-12068</guid>
		<description>I don&#039;t agree with your analysis of why XSS gets more attention. I don&#039;t think its because its so easy to exploit, I think its because there are many more interesting things to do, and because there is so much more to discover.

With SQL, barring encoding issues, you either escape things or you don&#039;t.

With XSS, we are generally more interested in filter evasion, rather than finding a website which echoes our html right back. There is no such thing as an SQL Injection filter which allows users to enter some SQL commands, but tries to stop them executing others.

Furthermore with SQL it is perfectly clear where things need to be escaped, with XSS, even that is not a certainty, especially if you consider the FindMimeFromData issues in IE.

And besides hashing data, etc, there is not much you can do in terms of defence in depth, whereas to prevent XSS you can.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t agree with your analysis of why XSS gets more attention. I don&#8217;t think its because its so easy to exploit, I think its because there are many more interesting things to do, and because there is so much more to discover.</p>
<p>With SQL, barring encoding issues, you either escape things or you don&#8217;t.</p>
<p>With XSS, we are generally more interested in filter evasion, rather than finding a website which echoes our html right back. There is no such thing as an SQL Injection filter which allows users to enter some SQL commands, but tries to stop them executing others.</p>
<p>Furthermore with SQL it is perfectly clear where things need to be escaped, with XSS, even that is not a certainty, especially if you consider the FindMimeFromData issues in IE.</p>
<p>And besides hashing data, etc, there is not much you can do in terms of defence in depth, whereas to prevent XSS you can.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pdp</title>
		<link>http://michaeldaw.org/news/sql-injection-sleeping-giant/comment-page-1#comment-12012</link>
		<dc:creator>pdp</dc:creator>
		<pubDate>Fri, 09 Mar 2007 16:17:16 +0000</pubDate>
		<guid isPermaLink="false">http://michaeldaw.org/news/sql-injection-sleeping-giant/#comment-12012</guid>
		<description>I don&#039;t quite agree. XSS can be as complicated as SQL Injection and sometimes even more. Both types of vulnerabilities are easy to find. However, both of them require some expertise to exploit them.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t quite agree. XSS can be as complicated as SQL Injection and sometimes even more. Both types of vulnerabilities are easy to find. However, both of them require some expertise to exploit them.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
