StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<h2>A. In general…</h2> <ol> <li><p>I’m assuming here that the programmer is not also the server administrator, and that the server admin more or less knows how to configure LAMP correctly and securely by default.</p> <p>Of course, if necessary, a programmer can override most PHP settings in a custom <code>php.ini</code> file located in the web root.</p></li> <li><p>Use an MVC framework.</p> <p>I use CakePHP. The framework itself goes a long way to ensure fundamentally sound and secure coding practices.</p></li> </ol> <h2>B. Incoming data…</h2> <ol> <li><p>Sanitize and validate all data contained in <code>$_GET, $_POST, $_COOKIE,</code> and <code>$_REQUEST</code> before programmatically manipulating the data.</p></li> <li><p>SQL Injection</p> <p><strong>Definition:</strong> Code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed.</p> <p><strong>Prevention:</strong> Parameterised queries using a library such as <code>mysqli</code> or <code>PDO</code>. See the <a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet" rel="nofollow noreferrer">OWASP SQL Injection cheat sheet</a> (string escaping functions like <code>mysql_real_escape_string</code> are <em>not</em> recommended)</p></li> <li><p>Cross Site Scripting (XSS)</p> <p><strong>Definition:</strong> Security vulnerability typically found in web applications that allows code injection by malicious web users into the web pages viewed by other users. Examples of such code include client-side scripts (i.e., JavaScript).</p> <p><strong>Prevention:</strong> <em>Context-dependent</em> output escaping and encoding. See the <a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet" rel="nofollow noreferrer">OWASP XSS prevention cheat sheet</a>.</p></li> </ol> <h2>C. Browser requests…</h2> <ol> <li><p>Cross Site Request Forgery (CSRF)</p> <p><strong>Definition:</strong> Type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.</p> <p><strong>Prevention:</strong> Generate a unique “token”, typically when a browser session starts. Pass the token in all <code>POST</code> and <code>GET</code> requests. Following the <code>POST</code>/<code>GET</code> action, check for the existence of the token in the session and then confirm the token sent by <code>POST</code>/<code>GET</code> is identical to the token stored in the session. (An MVC framework like CakePHP makes this relatively easy to implement uniformly throughout your application.)</p></li> </ol> <h2>D. Sessions…</h2> <ol> <li><p>Destroy session data when killing a session</p> <p>After a session is complete (”logout”), destroy its data and don’t just clear the cookie (a malicious user could otherwise just re-instate the cookie and use the session again). Unset all indexes in <code>$_SESSION</code> by assigning it to an empty array.</p></li> <li><p>Store sessions as files above the web root or in a database</p> <p>The default path for saving sessions on the server can be hijacked -- especially in a shared hosting environment.</p></li> </ol> <h2>E. Passwords…</h2> <ol> <li><p>Enforce the selection of strong passwords</p> <ul> <li><p>Require numbers, symbols, upper and lowercase letters in passwords</p></li> <li><p>Password length should be around 12 to 14 characters</p></li> </ul></li> <li><p>Hash and Salt all passwords</p> <p><strong>Do not use <code>sha1()</code>, <code>md5()</code> or <code>hash()</code> to hash passwords</strong>. They're not designed for this. You will want to use a function like <a href="https://stackoverflow.com/questions/4795385/how-do-you-use-bcrypt-for-hashing-passwords-in-php?lq=1">bcrypt</a> or PBDFK2. There's <a href="https://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords">some really good suggestions on this question</a>. Your salt value should be completely random, and stored in the database (it's not really a secret). An additional secret value (generally called "pepper") can be stored in your application and prepended to passwords before using bcrypt, but it's not clear how much security this really adds.</p></li> </ol> <h2>F. In a custom <code>php.ini</code> located in web root…</h2> <ol> <li><p>Disable register_globals</p> <p><strong>Prevention:</strong> <code>register_globals = Off</code></p></li> <li><p>Disable magic quotes</p> <p><strong>Prevention:</strong> <code>magic_quotes_gpc = Off</code></p></li> <li><p>Disable error reporting</p> <p><strong>Prevention:</strong> <code>display_errors = Off</code></p></li> <li><p>Enable error logging and save log file to a directory above web root</p> <p><strong>Prevention:</strong></p> <pre><code>log_errors = On; ignore_repeated_errors = On; html_errors = Off; error_log = /path/above/webroot/logs/php_error_log </code></pre></li> <li><p>Store session data inside a directory above web root</p> <p><strong>Prevention:</strong> <code>session.save_path = /path/above/webroot/sessions</code></p></li> </ol> <h2>G. In a <code>.htaccess</code> file located in web root…</h2> <ol> <li><p>Disable directory listings site-wide</p> <p><strong>Prevention:</strong> <code>Options -Indexes</code></p></li> </ol> <h2>H. Valuable/Sensitive files…</h2> <ol> <li><p>Prevent unauthorized access/downloads by storing such files above the web root</p> <p>This includes site administration/members-only sections and site/database configuration files!!</p></li> <li><p>Use an intermediary script to serve the files inline or as an attachment</p></li> <li><p>Keep your scripts(WordPress, PHPMyAdmin, etc.) updated.</p></li> <li><p>Only allow access to PHPMyAdmin when you are using it. This prevents people from being able to use zero-day exploits on your install.</p></li> </ol> <h2>I. Uploaded files…</h2> <ol> <li><p>Validate file name stored in <code>$_FILES</code> before using it for any kind of data manipulation</p></li> <li><p>Be aware that the provided mime type can be spoofed or otherwise wrong</p></li> <li><p>Move all user-uploaded files to a directory above web root!!!</p></li> <li><p>Don’t execute/serve uploaded files with include()</p></li> <li><p>Try to not serve files with content types of “application/octet-stream,” “application/unknown,” or “plain/text”</p></li> </ol> <h2>J. Misc…</h2> <ol> <li><p>All “utility” files/programs in the web root created and used by the developer during the development of a site/application, that are not intended or required to be accessed by future site users, or otherwise pose some kind of security risk, should be removed when the site goes live.</p> <p>For example, this includes a <code>phpinfo.php</code> file (a files that prints the results of <code>phpinfo()</code>), database utility scripts, etc.</p></li> </ol>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload