有些系统中，环境变量存储了和系统有关的一些配置信息，如在Linux中，很多程序配置被环境变量以某些隐含、模糊或未公开的方式所定义。例如，sh和bash shell使用IFS变量来决定分隔命令行参数的字符。那么，在执行一个shell时，把IFS设置为某些值，就可能进行攻击。
另一方面，由于并不是所有的环境变量都有文档的说明，这让用户遇到攻击之后无所适从；并且由于环境变量的可编辑性，攻击者甚至可以增加一些更加危险的环境变量，来达到攻击的目的。
（2）环境变量的存储格式给攻击者机会。在Linux下，环境变量在底层，通常是以字符申数组形式存储的，这个字符串指针数组有一个头指针，该数组中，按顺序存储各个环境变量，每一个环境变量是这个数组中的一个元素，该数组以NULL.指针结尾。
每一个元素的格式都为NAME=value。
这就潜在地说明，环境变量名不能包含等号，也不能包含一些其他敏感符号，如NIL（ASCI码为0的字符，一般表示一个字符串结尾）。但是如果这一点被攻击者利用，也会给系统带来损害。
实际上，环境变量方面的安全问题还有很多，读者可以参考相关文档。
如何解决以上安全问题？可从以下几个方面着手：
限制环境变量的使用权限；
可适当破坏环境变量在shell之间的共享；·对用户定义的环境变量，需要进行严格的检查。
3.2.4 文件名安全问题在很多和文件输出有关的系统中，文件名有可能成为安全隐患。无论在什么样的操作系统中，文件名应该遵循以下安全准则：
（1）***不要让用户来自己输入文件名，应该在界面上给用户一个默认的文件名。如Windows中将文件另存时，界面中“文件名”框中，会显示一个默认的合法名称，避免用户因为输入一些不合法的文件名造成安全问题。
（2）如果不得不让用户输入文件名，那么***将文件名限制只能含有字母和数子。
特别应该考虑将一些特殊字符如/、\、、.和通配符（如*、？、[]和{}）等从合法模式中去掉。
例如，如果文件名中可以用-，有一个文件名为-rf，那么在UNIX/Linux中执行命令rm*，将会变成执行rm-rf。这实际上是一个安全隐患。
（3）不要允许用户命名一些可能和物理设备冲突的文件名。比如，在一些系统中，一些文件名可以被认为是物理设备。例如，如果一个程序试图去打开COM1文件，可能被系统误解为是尝试和串口通信，系统就去进行串口的读写，而该操作又不是用户的朗望。因此，该种文件命名也要避免。
攻击者通过对数据库的恶意输入，可以将信息注入正在运行的流程，获联敏感效据，甚至危害进程的运行状态。
例如以下常见代码:
String sql = "select * From T_CUSTOMER where name = \'"+name+"\'";变量name是由用户提供。这个SQL语句看上去没有问题，如果用户的输入为name=lihua，它将创建完整、良好的SQL语句.
但是这可能会给用户恶意输入的机会。该SQL语句的问题在于攻击者可在变量name中植入SQL语句。如果用户的输入为：lihua\'OR1=1--，语句变为：
select * From T_CUSTOMER where name = \'lihua\'or 1=1 --这条语句将返回表T_CUSTOMER列NAME值为lihua的行，或者所有满足1=1子句的行。而对于表中的每一行，1=1都返回true，因此表中的所有行都将被返回，此种情况下，攻击者将能够获得表T_CUSTOMER中所有数据。
攻击者通过这种技术，可以完成以下攻击活动：
改变一条SQL语句的具体条件；
添加并且运行额外的SQL的语句；
秘密调用函数和存储过程。
在有些数据库产品中允许一次性运行多条语句，这给攻击者更大的攻击空间。如上面的例子，如果攻击者输入：lihua\'；DROP TABLE T_CUSTOMER--，语句变为：
select * From T_CUSTOMER where name = \'lihua\';DROP TABLE T_CUSTOMER--这条语句将返回表T_CUSTOMER列NAME值为lihua的行，然后删除T_CUSTOMER表。此外，这种攻击还包括各种可以改变数据库结构的操作，例如创圭、删除以及更新数据库对象等。
3.3.3 账户和口令问题在应用程序中，连接到数据库通常要确定账户和口令。但是很多程序员对这一点不讲究，直接用管理员账户连接到数据库，这是很危险的。例如，在SQL Server中，以sa进行连接是很危险的，在Oracle数据库中，以system进行连接也是很危险的，它们都是功能强大且很可能对各自系统造成损害的账户。