<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>coffeecoders.de &#187; security</title>
	<atom:link href="http://coffeecoders.de/tag/security/feed/" rel="self" type="application/rss+xml" />
	<link>http://coffeecoders.de</link>
	<description>professional devs at work</description>
	<lastBuildDate>Tue, 13 Sep 2011 16:34:02 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Get rid off phpmail()!</title>
		<link>http://coffeecoders.de/2009/08/get-rid-off-phpmail/</link>
		<comments>http://coffeecoders.de/2009/08/get-rid-off-phpmail/#comments</comments>
		<pubDate>Mon, 31 Aug 2009 13:06:29 +0000</pubDate>
		<dc:creator>stevie</dc:creator>
				<category><![CDATA[common]]></category>
		<category><![CDATA[administration]]></category>
		<category><![CDATA[php]]></category>
		<category><![CDATA[security]]></category>

		<guid isPermaLink="false">http://coffeecoders.de/?p=222</guid>
		<description><![CDATA[Dear sysadmins and developers, phpmail() IS OUT! Get rid off it. Now! One of the most common sources of spam are &#8220;hacked&#8221; webservers and poorly or even non-secured forms. By using phpmail the webserver must be allowed to send mails &#8230; <a href="http://coffeecoders.de/2009/08/get-rid-off-phpmail/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>Dear sysadmins and developers,</p>
<p><a href="http://www.php.net/phpmail">phpmail()</a> IS OUT! Get rid off it. Now!</p>
<p>One of the most common sources of spam are &#8220;hacked&#8221; webservers and poorly or even non-secured forms. By using phpmail the webserver must be allowed to send mails without checks for a valid sender. This results &#8211; mostly on a shared web host &#8211; in having checking every clients installations for the bad script while the mailserver gets blacklisted due to the spam wave.<br />
<span id="more-222"></span><br />
There are enough possibilities out there on how to send mail without using phpmail such as <a href="http://pear.php.net/package/Net_SMTP/">PEAR Net_SMTP</a>. I even encourage every webmaster to turn off phpmail by blacklisting this function in php.ini. This way the developers would be forced to name an smtp account for sending mail which is <em>much</em> easier to track (and shut off if neccessary).</p>
]]></content:encoded>
			<wfw:commentRss>http://coffeecoders.de/2009/08/get-rid-off-phpmail/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>TOP 25 Most Dangerous Programming Errors</title>
		<link>http://coffeecoders.de/2009/01/top-25-most-dangerous-programming-errors/</link>
		<comments>http://coffeecoders.de/2009/01/top-25-most-dangerous-programming-errors/#comments</comments>
		<pubDate>Wed, 14 Jan 2009 11:11:30 +0000</pubDate>
		<dc:creator>stevie</dc:creator>
				<category><![CDATA[common]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[coding]]></category>
		<category><![CDATA[link]]></category>
		<category><![CDATA[security]]></category>

		<guid isPermaLink="false">http://coffeecoders.de/?p=79</guid>
		<description><![CDATA[I recently found a document, stating it contains the most dangerous programming errors. The layout of this article is very &#8230; let&#8217;s say technical so I was about to close this one because it&#8217;s not very much fun to read &#8230; <a href="http://coffeecoders.de/2009/01/top-25-most-dangerous-programming-errors/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>I recently found a document, stating it contains the most dangerous programming errors. The layout of this article is very &#8230; let&#8217;s say technical so I was about to close this one because it&#8217;s not very much fun to read it. But the first few lines took me in and I read the whole thing. I wonder if it has the same impact on you:</p>
<p><span id="more-79"></span></p>
<blockquote><p>Today in Washington, DC, experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale.</p>
<p>The impact of these errors is far reaching. Just two of them led to more than 1.5 million web site security breaches during 2008 &#8211; and those breaches cascaded onto the computers of people who visited those web sites, turning their computers into zombies.</p>
<p>[...much more...]</p></blockquote>
<p>If you are a programmer and have the urge to make a perfect application you have to admit that this excerpt teases you. You want to know if you are better than these guys who messed up epically.</p>
<p>Let&#8217;s see, which errors could you have made?</p>
<p>Well, of course, we have the three regulars <strong>SQL Injection</strong>, <strong>Cross Site Scripting</strong> and <strong>OS Command Injection</strong>. These three are still very common although there are a various number of best practises available to prevent them.</p>
<p>So if you have one of these in your application you would be in good company but you will have ignored some basic rules like &#8220;<em>Don&#8217;t trust user input!</em>&#8220;.</p>
<p>Ok, moving on. What else is there password- and cryptographie-related errors are often a source of fun or blank horror. There are the ones where you should have watched the newspages like &#8220;<strong>Use of a Broken or Risky Cryptographic Algorithm</strong>&#8220;, things you should know to avoid like &#8220;<strong>Hard-Coded Password</strong>&#8221; and &#8220;<strong>Client-Side Enforcement of Server-Side Security</strong>&#8221; and things you could have tested properly like &#8220;<strong>Execution with Unnecessary Privileges</strong>&#8221; or &#8220;<strong>Improper Access Control (Authorization)</strong>&#8220;.</p>
<p>I know, i know &#8211; you would have done (or not done) all these things if you just had enough time for it. Well, I know the clients and I know that they don&#8217;t have the feeling for tasks like &#8220;testing&#8221;. They can&#8217;t possibly understand why such a task is taking so much time. But as reality shows it is wise to invest a big chunk of your development time into it.</p>
<p>So it is <em>your</em> tasks to make sure the client (or your boss for that matter) understands the need for testing and making &#8220;unnecessarry&#8221; code for checking user input etc. It is in both his/her interest and yours to produce an application holding up against real world scenarios and bored high school kids.</p>
<p>Link: <a href="http://www.sans.org/top25errors/#s4">SANS Institute &#8211; CWE/SANS TOP 25 Most Dangerous Programming Errors</a>.</p>
]]></content:encoded>
			<wfw:commentRss>http://coffeecoders.de/2009/01/top-25-most-dangerous-programming-errors/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

