Editing Code injection (section)

==Preventing Code Injection==
To prevent code injection problems, the person could use secure input and output handling strategies, such as:
* Using an [[application programming interface]] ([[API]]) that, if used properly, is secure against all input characters. Parameterized queries allow the moving of user data out of a string to be interpreted. Additionally, Criteria API<ref>{{cite web|title=The Java EE 6 Tutorial: Chapter 35 Using the Criteria API to Create Queries|url=http://docs.oracle.com/javaee/6/tutorial/doc/gjitv.html|publisher=Oracle|access-date=19 December 2013|archive-date=11 November 2013|archive-url=https://web.archive.org/web/20131111182712/http://docs.oracle.com/javaee/6/tutorial/doc/gjitv.html|url-status=live}}</ref> and similar APIs move away from the concept of command strings to be created and interpreted.
* Enforcing language separation via a [[Type system|static type system]].<ref name="types">{{cite web | last=Moertel | first=Tom | title=A type-based solution to the "strings problem": a fitting end to XSS and SQL-injection holes? | website=Tom Moertel's Blog | date=2006-10-18 | url=http://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html | access-date=2018-10-21 | archive-date=6 August 2013 | archive-url=https://web.archive.org/web/20130806145659/http://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html | url-status=live }}</ref>
* Validating or "sanitizing" input, such as [[whitelisting]] known good values. This can be done on the client side, which is prone to modification by malicious users, or on the server side, which is more secure.
* Encoding input or escaping dangerous characters. For instance, in PHP, using the <code>htmlspecialchars()</code> function to escape special characters for safe output of text in HTML and the <code>mysqli::real_escape_string()</code> function to isolate data which will be included in an [[SQL]] request can protect against SQL injection.
* Encoding output, which can be used to prevent [[Cross-site scripting|XSS]] attacks against website visitors.
* Using the <code>HttpOnly</code> flag for [[HTTP cookie]]s. When this flag is set, it does not allow client-side script interaction with cookies, thereby preventing certain [[Cross-site scripting|XSS]] attacks.<ref>{{Cite web|url=https://www.owasp.org/index.php/HttpOnly|title=HttpOnly|date=12 November 2014|website=OWASP|access-date=10 December 2016|archive-date=26 December 2008|archive-url=https://web.archive.org/web/20081226095717/http://www.owasp.org/index.php/HTTPOnly|url-status=live}}</ref>
* Modular shell disassociation from the [[Kernel (operating system)|kernel]].
* Regarding [[SQL injection]], one can use [[parameterized query|parameterized queries]], [[stored procedure]]s, whitelist input validation, and other approaches to help mitigate the risk of an attack.<ref>{{Cite web|url=https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet|title=SQL Injection Prevention Cheat Sheet|website=OWASP|access-date=10 December 2016|archive-date=20 January 2012|archive-url=https://web.archive.org/web/20120120064335/https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet|url-status=live}}</ref> Using [[object-relational mapping]] can further help prevent users from directly manipulating [[SQL queries]].

The solutions described above deal primarily with web-based injection of HTML or script code into a server-side application. Other approaches must be taken, however, when dealing with injections of user code on a user-operated machine, which often results in privilege elevation attacks. Some approaches that are used to detect and isolate managed and unmanaged code injections are:
* Runtime image [[Hash function|hash]] validation, which involves capturing the hash of a partial or complete image of the executable loaded into memory and comparing it with stored and expected hashes.
* [[NX bit]]: all user data is stored in special memory sections that are marked as non-executable. The processor is made aware that no code exists in that part of memory and refuses to execute anything found in there.
* Use [[Buffer overflow protection#Canaries|canaries]], which are randomly placed values in a stack. At runtime, a canary is checked when a function returns. If a canary has been modified, the program stops execution and exits. This occurs on a failed [[Stack buffer overflow|Stack Overflow Attack]].
* Code Pointer Masking (CPM): after loading a (potentially changed) code pointer into a register, the user can apply a [[Mask (computing)|bitmask]] to the pointer. This effectively restricts the addresses to which the pointer can refer. This is used in the [[C (programming language)|C]] programming language.<ref>{{cite journal | last1=Philippaerts | first1=Pieter | last2=Younan | first2=Yves | last3=Muylle | first3=Stijn | last4=Piessens | first4=Frank | last5=Lachmund | first5=Sven | last6=Walter | first6=Thomas | title=CPM: Masking Code Pointers to Prevent Code Injection Attacks | journal=ACM Transactions on Information and System Security | volume=16 | issue=1 | date=2013-06-01 | issn=1094-9224 | doi=10.1145/2487222.2487223 | pages=1–27 | s2cid=10947780 | url=http://fort-knox.org/files/tissec.pdf | display-authors=1 | access-date=21 October 2018 | archive-date=24 February 2021 | archive-url=https://web.archive.org/web/20210224082956/http://fort-knox.org/files/tissec.pdf | url-status=live }}</ref>