<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0">
    <channel>
        <title>DevZone - Items tagged as: Security Tips</title>
        <link>http://devzone.zend.com/</link>
        <description>advancing the art of PHP.  Best practices, samples, articles, news, and community for PHP 4, PHP 5, and beyond.</description>
        <lastBuildDate>Tue, 10 Apr 2007 17:40:41 +0000</lastBuildDate>
        <pubDate>Tue, 10 Apr 2007 17:40:41 +0000</pubDate>
        <docs>http://devzone.zend.com/public/view/tag/security_tips/format/rss2.0</docs>     
        <language>en-us</language> 
        <image>
          <title>DevZone - Items tagged as: Security Tips</title>
          <link>http://devzone.zend.com/</link>
          <url>http://devzone.zend.com/images/devzone_logo4.gif</url>
        </image>
                  <item>
            <title>Security Tip: Use a Database Abstraction Layer to help prevent SQL Injection</title>
            <pubDate>Tue, 10 Apr 2007 17:40:41 +0000</pubDate>
            <description>
                  
    SQL injections are a common vulnerability in web-based applications that use
    databases. As an example of a potential SQL injection, consider a login form
    asking only for a username, where the backend has code reading:
 

  
    mysql_query('SELECT * FROM user WHERE username = "' . $_GET['username'] . '");
  

 
    A malicious hacker could attempt to enter the value  ""; DELETE FROM
    user WHERE 1" , which would have the effect of removing all users in
    the table. (Granted, this won't happen with PHP's mysql extension as it will
    not execute multiple queries by default; this is just an illustration.)
 
            </description>
            <link>http://devzone.zend.com/article/1918-Security-Tip-Use-a-Database-Abstraction-Layer-to-help-prevent-SQL-Injection</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1918-Security-Tip-Use-a-Database-Abstraction-Layer-to-help-prevent-SQL-Injection</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #21 </title>
            <pubDate>Mon, 02 Apr 2007 13:24:46 +0000</pubDate>
            <description>
                 	 Today&#8217;s PHP security tip is short, sweet and easily actionable. It fits in well with the theme of the last one, to stay vigilant.  Here&#8217;s another resource for you to consider. 


 
            </description>
            <link>http://devzone.zend.com/article/1882-PHP-Security-Tip-21-</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1882-PHP-Security-Tip-21-</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #20</title>
            <pubDate>Fri, 30 Mar 2007 13:42:05 +0000</pubDate>
            <description>
                 	 To paraphrase an American Patriot &#8220;The price of security is eternal vigilance&#8221;. You have to keep watch over your system but you also have to keep learning. 

 
            </description>
            <link>http://devzone.zend.com/article/1877-PHP-Security-Tip-20</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1877-PHP-Security-Tip-20</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #19</title>
            <pubDate>Thu, 29 Mar 2007 13:36:13 +0000</pubDate>
            <description>
                 	 Sometimes, the best application security you can install is simply disconnecting the network cable from your server. 

 
            </description>
            <link>http://devzone.zend.com/article/1871-PHP-Security-Tip-19</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1871-PHP-Security-Tip-19</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #18</title>
            <pubDate>Wed, 28 Mar 2007 13:29:23 +0000</pubDate>
            <description>
                 	 When you allow users to upload files, your system may be at risk.  Handle file upload scripts with care. Without proper security precautions, you can leave a gaping hole in your system. 


 
            </description>
            <link>http://devzone.zend.com/article/1867-PHP-Security-Tip-18</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1867-PHP-Security-Tip-18</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #17</title>
            <pubDate>Tue, 27 Mar 2007 14:13:30 +0000</pubDate>
            <description>
                  Application security should not be a "when all else fails" situation. It's not something you can "put in later". As we've mentioned before, there is no single silver bullet to solve your application security issues. Security is something that should be rolling around in the back of your dead in the design phase, the coding phase, the testing phase, even after you've rolled your code into production.  
            </description>
            <link>http://devzone.zend.com/article/1866-PHP-Security-Tip-17</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1866-PHP-Security-Tip-17</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #16</title>
            <pubDate>Mon, 26 Mar 2007 13:41:48 +0000</pubDate>
            <description>
                 	 This idea was originally posted as a comment to a previous PHP Security Tip. I believe that this is an important issue, and worth being a tip itself. 

 
            </description>
            <link>http://devzone.zend.com/article/1857-PHP-Security-Tip-16</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1857-PHP-Security-Tip-16</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #15</title>
            <pubDate>Fri, 23 Mar 2007 11:59:34 +0000</pubDate>
            <description>
                 	 As developers, most of us are very messy. I&#8217;ve worked on countless projects and at each either run across or left a trail of diagnostic files laying around.  

 
            </description>
            <link>http://devzone.zend.com/article/1849-PHP-Security-Tip-15</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1849-PHP-Security-Tip-15</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #14</title>
            <pubDate>Wed, 21 Mar 2007 14:25:02 +0000</pubDate>
            <description>
                 	 Almost any application running PHP on the back-end uses web technologies for it&#8217;s front end. Many developers who think hard on PHP security, don&#8217;t spend a thought on front-end security for their application. Here&#8217;s a tip to think long and hard about when building your HTML and JavaScript. 


 
            </description>
            <link>http://devzone.zend.com/article/1842-PHP-Security-Tip-14</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1842-PHP-Security-Tip-14</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #13</title>
            <pubDate>Tue, 20 Mar 2007 12:43:44 +0000</pubDate>
            <description>
                 	 Security is a mindset, not just something you do. It colors your application design as well as your coding. However, you also need to constantly monitor your production environment. That&#8217;s where selecting the right tool comes into play.  


 
            </description>
            <link>http://devzone.zend.com/article/1833-PHP-Security-Tip-13</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1833-PHP-Security-Tip-13</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #12</title>
            <pubDate>Fri, 16 Mar 2007 13:46:09 +0000</pubDate>
            <description>
                 	 We&#8217;ve talked about filtering, we&#8217;ve talked about validating, we&#8217;ve talked about filtering again. Filtering inputs into your application is an important concept and the pre-cursor to many good security practices. However, once you have the input filtered and validated you can&#8217;t simply sit back and relax. You have to stay vigilant when programming to ensure security throughout your application. 


 
            </description>
            <link>http://devzone.zend.com/article/1821-PHP-Security-Tip-12</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1821-PHP-Security-Tip-12</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #11</title>
            <pubDate>Thu, 15 Mar 2007 16:59:01 +0000</pubDate>
            <description>
                 	 I think we can all agree that users are at once the boon and the bane of our applications.  On the one hand, if it weren&#8217;t for users, we wouldn&#8217;t have security problems. On the other hand, if we didn&#8217;t have users, we wouldn&#8217;t need the application to begin with. So we can all agree with the fact that in most cases, users aren&#8217;t going away.  

 
            </description>
            <link>http://devzone.zend.com/article/1817-PHP-Security-Tip-11</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1817-PHP-Security-Tip-11</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #10</title>
            <pubDate>Wed, 14 Mar 2007 19:30:57 +0000</pubDate>
            <description>
                 	 Even when doing everything correctly, it&#8217;s still possible to build PHP applications that are insecure. Security requires constant vigilance. One thing you always have to keep your eye on is any script or form that sends an email based on use input. 

 
            </description>
            <link>http://devzone.zend.com/article/1815-PHP-Security-Tip-10</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1815-PHP-Security-Tip-10</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #9</title>
            <pubDate>Tue, 13 Mar 2007 14:44:54 +0000</pubDate>
            <description>
                 	 Sometimes it&#8217;s the simplest ideas that are the most powerful.  This one sounds simple but I&#8217;m always surprised at how few people understand and actually implement this idea. 

 
            </description>
            <link>http://devzone.zend.com/article/1807-PHP-Security-Tip-9</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1807-PHP-Security-Tip-9</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #8</title>
            <pubDate>Mon, 12 Mar 2007 13:57:02 +0000</pubDate>
            <description>
                 	 Within PHP security topics, there is always more than one way to accomplish a task.  Many times it&#8217;s by combining tactics that we achieve the best security.   

 
            </description>
            <link>http://devzone.zend.com/article/1793-PHP-Security-Tip-8</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1793-PHP-Security-Tip-8</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #7</title>
            <pubDate>Fri, 09 Mar 2007 13:34:46 +0000</pubDate>
            <description>
                 	 When using session_regenerate_id() to protect against session fixation it&#8217;s usually a good idea to remove the old session ID. 


 
            </description>
            <link>http://devzone.zend.com/article/1786-PHP-Security-Tip-7</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1786-PHP-Security-Tip-7</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #6</title>
            <pubDate>Thu, 08 Mar 2007 18:37:04 +0000</pubDate>
            <description>
                 	 The topic of writing secure applications in PHP covers more than just writing good PHP code. Most applications make use of a database of some kind.  Many times, vulnerabilities that affect the entire application, are introduced when building the SQL code. 

 
            </description>
            <link>http://devzone.zend.com/article/1778-PHP-Security-Tip-6</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1778-PHP-Security-Tip-6</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #5</title>
            <pubDate>Wed, 07 Mar 2007 13:46:41 +0000</pubDate>
            <description>
                 	 PHP security is an ongoing mission requiring the programmer to think outside of the parameters of the application.  It&#8217;s not enough these days to say in your mind &#8220;Does this do what I want it to do?&#8221; you also have to take into consideration &#8220;What else can people use it for and do I want to allow that?&#8221;  


 
            </description>
            <link>http://devzone.zend.com/article/1767-PHP-Security-Tip-5</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1767-PHP-Security-Tip-5</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #4</title>
            <pubDate>Tue, 06 Mar 2007 14:46:00 +0000</pubDate>
            <description>
                 	 &#8220;Security through obscurity is no security at all.&#8221; so the adage goes.  However, the flip side of that coin is, obscurity, when used as part of an overall strategy, is a good thing. 

 
            </description>
            <link>http://devzone.zend.com/article/1761-PHP-Security-Tip-4</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1761-PHP-Security-Tip-4</guid> 
          </item>
                  <item>
            <title>PHP Security Tip #3</title>
            <pubDate>Mon, 05 Mar 2007 14:30:51 +0000</pubDate>
            <description>
                 	 Being Security conscious is a good thing but that alone won&#8217;t solve the problem. Developers have to be vigilant when it comes to security.  Even then you can&#8217;t do it alone. Today&#8217;s Security tip reminds you of this. 


 
            </description>
            <link>http://devzone.zend.com/article/1754-PHP-Security-Tip-3</link>
            <guid isPermaLink="true">http://devzone.zend.com/article/1754-PHP-Security-Tip-3</guid> 
          </item>
            </channel>
</rss>

