Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h2>Background</h2> <p>The vulnerabilities you mentioned all stem from a confusion of data with control (or code, if you'd prefer). They arise in practice because many programming languages and APIs aren't equipped to encode the semantics of domain-specific languages like SQL, HTML, and the system shell. For example, nearly all XSS vulnerabilities occur because a programmer prints out an un-sanitized string and the programming language or API doesn't have enough information to detect that the string was user-submitted and should have had its control characters escaped. Fortunately, there are language extensions and APIs that do separate data from control and can eliminate nearly all of these attacks.</p> <h2>SQL Injections</h2> <ul> <li><strong>Prepared statements.</strong> The <a href="http://download.oracle.com/javase/tutorial/jdbc/basics/prepared.html" rel="nofollow noreferrer" title="JDBC Prepared Statements">JDBC prepared statement</a> implementation for Java is the de facto standard for accessing DBMSes at the SQL level. You write SQL queries with variables, and then specify the values of those variables and their types, effectively giving the DBMS enough information to escape your data while leaving your query structure (the control) alone.</li> <li><strong>Query builders.</strong> Instead of specifying a query as a string, you can represent it as a sequence of method calls that gradually build up an object, in the fashion of the builder pattern. You might think of it as building up an AST by hand and then serializing it as a query string. There is a <a href="http://www.cs.ucsb.edu/~vigna/publications/2009_robertson_vigna_WebTyping.pdf" rel="nofollow noreferrer">paper</a> by Robertson and Vigna that illustrates some examples in Haskell.</li> <li><strong>LINQ.</strong> This is specific to .NET. Queries are effectively part of the language, so the parser can distinguish between query keywords and data. Once again, this allows the language to safely escape only the data. Due to my lack of experience with LINQ I can't say much more, but presumably data values are wrapped in <a href="http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlparameter.aspx" rel="nofollow noreferrer">SqlParameter</a> objects that are subsequently escaped.</li> <li><strong>ORM frameworks.</strong> A level above SQL injections, ORM frameworks aim to abstract away most of the DBMS details, including the queries themselves. They may use prepared statements behind the scenes, or even expose a prepared-statement-like API for more direct access to the database (for example, Hibernate's <a href="http://docs.jboss.org/hibernate/stable/core/reference/en/html/querysql.html" rel="nofollow noreferrer">SQLQuery</a>).</li> </ul> <h2>Cross-site Scripting (XSS)</h2> <p>Many of the techniques for preventing XSS attacks are similar in spirit to defenses against SQL injections. Only this time, the target is the web browser instead of the database. Either way, we don't want data to be mistakenly interpreted as control.</p> <ul> <li><strong>Templates.</strong> Most of the popular templating languages seem to be targeted at PHP, Python, or Ruby. However, there are a few out there <a href="https://stackoverflow.com/questions/174204/suggestions-for-a-java-based-templating-engine">for Java</a> and <a href="https://stackoverflow.com/questions/340095/can-you-recommend-a-net-template-engine">for .NET</a>. A template usually consists of HTML and placeholders for data to go. You then pass your data into the template engine, it escapes it all, and then it renders the template with the placeholders replaced with the sanitized data.</li> <li><strong>DOM tree builders.</strong> Similar to the SQL-query builders, you might construct a page using a DOM-like API to create new elements and text nodes, and finally serialize them as an HTML string at the end. Debatably, the standard DOM API is unfortunately too verbose for this approach to be palatable.</li> <li><strong>XML literals.</strong> Like LINQ, XML literals are a native part of a language that allows the parser to distinguish markup from data. While neither Java nor C# support XML literals, <a href="http://www.scala-lang.org/node/131" rel="nofollow noreferrer">Scala does</a> and <a href="http://msdn.microsoft.com/en-us/library/bb384563.aspx" rel="nofollow noreferrer">so does VB9</a>. Facebook has an open-source PHP extension called <a href="http://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919" rel="nofollow noreferrer">XHP</a> that provides several software engineering benefits as well, including component reuse and being able to specify content models for custom tags.</li> <li><strong>Heuristics and detection.</strong> This isn't a sure-fire defense, but some systems examine the HTML output and guess if malicious script is embedded. However, as people discovered with IE8, this can <a href="http://p42.us/ie8xss/Abusing_IE8s_XSS_Filters.pdf" rel="nofollow noreferrer">enable attacks</a>.</li> <li><strong>HTTP-only cookies.</strong> This is <strong>not</strong> a defense against XSS, but it can prevent quite a few attacks. When your server sets a cookie, it can mark it as <a href="http://www.owasp.org/index.php/HttpOnly" rel="nofollow noreferrer">HTTP-only</a>, meaning that supported browsers won't let JavaScript on a page access that cookie. Thus, even if an attacker is able to embed malicious script on your site, they won't be able to steal your user's cookies, provided they have a reasonably modern browser (even IE6+ counts!).</li> </ul> <h2>Remote Code Execution</h2> <p>I don't have much to say on this topic, but try to minimize <code>system()</code>-like calls as much as possible. If you have to make calls to other binaries, apply good security practices such as using a whitelist where possible and using well-vetted sanitization functions where appropriate. Some APIs, like Python's <a href="http://docs.python.org/library/subprocess.html#subprocess.Popen" rel="nofollow noreferrer">Popen</a>, do a nice job of ensuring that arguments aren't treated as shell control characters. Finally, with Java and C#, buffer overflow exploits are highly unlikely. It's not a formal guarantee, but billion-dollar companies run Java servers all the time.</p> <h2>Best Practices</h2> <p>Ultimately, you should consider using an API or language features that are designed for the task at hand, whether it is creating a SQL query or building an HTML page. Not only do these languages and APIs increase your confidence with regard to security, but they often facilitate programming as well. Compared with the old-school tactic of concatenating a bunch of strings, we now have LINQ and XML literals that arguably make code easier to write, easier to read, and also easier to verify. I'm a fan of language enhancements and APIs that improve both code quality and programmer productivity!</p>
 

Querying!

 
Guidance

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