본 글에서 다루는 보안 환경은 Linux+Apache+Mysql+PHP이다. 이 범위를 벗어나는 보안 문제는 이 글의 범위를 벗어납니다
1. Apache 서버 보안 설정
1 , 아무도 사용자로 실행
일반적으로 Apache는 Root에 의해 실행됩니다. 설치하고 실행합니다. Apache 서버 프로세스에 루트 사용자 권한이 있으면 시스템 보안에 큰 위협이 됩니다. Apache를 확인해야 합니다. 서버 프로세스는 가능한 가장 낮은 권한을 가진 사용자로 실행됩니다. httpd.conf 파일에서 다음 옵션을 수정하여 아무도 사용자로 Apache를 실행하십시오. 상대적인 안전성을 확보합니다. 사용자 없음 그룹# -12. ServerRoot 디렉터리 권한
모든 구성이 적절하고 안전한지 확인하려면 수퍼유저가 아닌 사람이 이 디렉토리의 내용을 수정할 수 없도록 Apache 홈 디렉토리에 대한 액세스를 엄격하게 제어해야 합니다. Apache의 홈 디렉터리는 Apache 서버 구성 파일 httpd.conf의 서버 루트 제어 항목에 해당합니다. 이어야 합니다. 서버 루트 /usr/local/apache3.SSI 구성
Apache 서버에서 실행 기능을 비활성화하려면 구성 파일 access.conf 또는 httpd.conf의 옵션 지시문에 NO EXEC 포함 옵션을 추가하세요. 사용자가 Apache 서버에서 실행 프로그램을 직접 실행하여 서버 시스템이 노출되는 것을 방지합니다. 옵션에는 Noexec가 포함됩니다4. 사용자가 시스템 설정을 수정하지 못하도록 방지
사용자가 .htaccess 파일을 생성 및 수정하지 못하도록 하고 사용자가 정의된 시스템 보안 기능을 초과하지 못하도록 하려면 Apache 서버 구성 파일에서 다음 설정을 지정하십시오. AllowOveride 없음 옵션 없음 모두 허용 그런 다음 특정 디렉터리를 적절하게 구성합니다.5. Apache 서버의 기본 액세스 특성 변경
Apache의 기본 설정은 특정 수준의 보안만 보장할 수 있습니다. 서버가 일반적인 매핑 규칙을 통해 파일을 찾을 수 있으면 클라이언트는 파일을 얻습니다. 예를 들어, 로컬 호스트/~ 루트/는 사용자가 전체 파일 시스템ord파일 시스템에 대한 기본 액세스가 비활성화됩니다.
6. CGI 스크립트 보안 고려사항 CGI 스크립트는 웹 서버를 통해 실행될 수 있는 일련의 프로그램입니다. 시스템의 보안을 보장하려면 CGI 작성자를 신뢰할 수 있는지 확인해야 합니다. CGI의 경우 특정 목적으로 제한하는 것이 가장 좋습니다. 또한 쉬운 관리를 위해 cgi-bin에 기록되며, 사용자에게 의미를 제공할 수 있는 경우 일부 사기성 프로그램이 파일에 상주하거나 혼합되는 것을 방지하기 위해 CGI 디렉토리의 파일을 쓸 수 없도록 해야 합니다. 보안의 좋은 CGI 프로그램 모듈을 참조로 사용하면 불필요한 문제와 보안 위험을 줄일 수 있으며 CGI 디렉토리에서 업무와 관련 없는 모든 응용 프로그램 스크립트를 제거하여 비정상적인 정보 유출을 방지할 수 있습니다.
7. SSL 링크 암호화 위의 일반적인 조치는 Apache Server에 기본적인 안전한 운영 환경을 제공할 수 있습니다. 물론 실제 애플리케이션과 일치하는 보안 구성 계획을 공식화하려면 특정 구현에서 더 자세한 분석이 필요합니다.
2. PHP 보안 설정 프로그램 취약점, 사용자 입력 양식 문제, PHP 파일 권한 문제 등 모든 보안 문제를 서버가 예방할 수는 없습니다. 또한 해커나 은밀한 동기를 가진 사람들을 혼란스럽게 하기 위해 몇 가지 수단을 사용할 수도 있습니다.
1. 프로그램 코드 취약점 문제 많은 PHP 프로그램의 주요 약점은 PHP 언어 자체의 문제가 아니라 프로그래머의 낮은 보안 인식에서 비롯됩니다. 따라서 잘못된 데이터 제출로 인해 발생할 수 있는 영향을 발견하려면 각 코드 부분에서 발생할 수 있는 문제에 항상 주의를 기울여야 합니다.
아아아아클라이언트에서 제출된 모든
변수가 올바르게 검사되도록 항상 코드에 주의를 기울여야 합니다. 확인해 보고 스스로에게 질문해 보세요.
이 스크립트는 예상되는 파일에만 영향을 줍니까?
비정상적인 데이터를 제출한 후에도 유효할 수 있나요?
이 스크립트를 의도하지 않은 목적으로 사용할 수 있나요?
이 스크립트를 다른 스크립트와 결합하여 나쁜 일을 할 수 있습니까?
모든 거래가 적절하게 문서화되어 있습니까?
在写代码的时候问自己这些问题,否则以后可能要为了增加安全性而重写代码了。注意了这些问题的话,也许还不完全能保证系统的安全,但是至少可以提高安全性。
还可以考虑关闭 register_globals,magic_quotes 或者其它使编程更方便但会使某个变量的合法性,来源和其值被搞乱的设置。
2、用户输入表单问题
验证用户输入的任何数据,保证PHP代码的安全。
注意1:JS只是为了提高来访用户的体验而产生的,而不是验证的工具。因为任何一个来访的用户都可能会,也有可能无意间就禁用了客户端脚本的执行,从而跳过这层验证。所以我们必须在PHP的服务器端程序上检验这些数据。
注意2:不要使用$_SERVER['HTTP_REFERER']这个超级变量来检查数据的来源地址,一个很小的菜鸟黑客都会利用工具来伪造这个变量的数据,尽可能利用Md5,或者rand等函数来产生一个令牌,验证来源的时候,验证这个令牌是否匹配。
3、PHP文件权限问题
PHP 被设计为以用户级别来访问文件系统,所以完全有可能通过编写一段 PHP 代码来读取系统文件如 /etc/passwd,更改网络连接以及发送大量打印任务等等。因此必须确保 PHP 代码读取和写入的是合适的文件。 请看下面的代码,用户想要删除自己主目录中的一个文件。假设此情形是通过 web 界面来管理文件系统,因此 Apache 用户有权删除用户目录下的文件。
<?php $username = $_POST['user_submitted_name']; $homedir = "/home/$username"; $file_to_delete = "$userfile"; unlink ("$homedir/$userfile"); echo "$file_to_delete has been deleted!"; ?>
既然 username 变量可以通过用户表单来提交,那就可以提交别人的用户名和文件名,并删除该文件。这种情况下,就要考虑其它方式的认证:
-只给 PHP 的 web 用户很有限的权限。 -检查所有提交上来的变量。 -以下是更加安全的文件名和变量的验证和检查:
<?php $username = $_SERVER['REMOTE_USER']; $homedir = "/home/$username"; if (!ereg('^[^./][^/]*$', $userfile)) die('bad filename'); if (!ereg('^[^./][^/]*$', $username)) die('bad username'); ?>
4、隐藏PHP扩展名
一般而言,通过隐藏的手段提高安全性被认为是作用不大的做法。但某些情况下,尽可能的多增加一份安全性都是值得的。
一些简单的方法可以帮助隐藏 PHP,这样做可以提高攻击者发现系统弱点的难度。在 php.ini 文件里设置 expose_php = off ,可以减少他们能获得的有用信息。
另一个策略就是让 web 服务器用 PHP 解析不同扩展名。无论是通过 .htaccess 文件还是 Apache 的配置文件,都可以设置能误导攻击者的文件扩展名:
# 使PHP看上去像其它的编程语言
AddType application/x-httpd-php .asp .py .pl
# 使 PHP 看上去像未知的文件类型
AddType application/x-httpd-php .bop .foo .133t
# 使 PHP 代码看上去像 HTML 页面
AddType application/x-httpd-php .htm .html
要让此方法生效,必须把 PHP 文件的扩展名改为以上的扩展名。这样就通过隐藏来提高了安全性,虽然防御能力很低而且有些缺点。
三、Mysql数据库安全性设置
PHP 本身并不能保护数据库的安全。下面的章节只是讲述怎样用 PHP 脚本对数据库进行基本的访问和操作。记住一条简单的原则:深入防御。保护数据库的措施越多,攻击者就越难获得和使用数据库内的信息。正确地设计和应用数据库可以减少被攻击的担忧。
1、数据库设计问题
应用程序永远不要使用数据库所有者或超级用户帐号来连接数据库,因为这些帐号可以执行任意的操作,比如说修改数据库结构(例如删除一个表)或者清空整个数据库的内容。以下截图的用户设置是危险的。
应该为程序的每个方面创建不同的数据库帐号,并赋予对数据库对象的极有限的权限。仅分配给能完成其功能所需的权限,避免同一个用户可以完成另一个用户的事情。这样即使攻击者利用程序漏洞取得了数据库的访问权限,也最多只能做到和该程序一样的影响范围。
2.数据库连接问题
把连接建立在 SSL 加密技术上可以增加客户端和服务器端通信的安全性,或者 SSH 也可以用于加密客户端和数据库之间的连接。如果使用了这些技术的话,攻击者要监视服务器的通信或者得到数据库的信息是很困难的。
3.数据库数据的加密
SSL/SSH 能保护客户端和服务器端交换的数据,但 SSL/SSH 并不能保护数据库中已有的数据。SSL 只是一个加密网络数据流的协议。
如果攻击者取得了直接访问数据库的许可(绕过 web 服务器),敏感数据就可能暴露或者被滥用,除非数据库自己保护了这些信息。对数据库内的数据加密是减少这类风险的有效途径,但是只有很少的数据库提供这些加密功能。
对于这个问题,有一个简单的解决办法,就是创建自己的加密机制,然后把它用在 PHP 程序内,最常见的例子就是把密码经过 MD5 加密后的散列存进数据库来代替原来的明文密码。
<?php $query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');", addslashes($username), md5($password)); $result = pg_query($connection, $query); $query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';", addslashes($username), md5($password)); $result = pg_query($connection, $query); if (pg_num_rows($result) > 0) { echo 'Welcome, $username!'; } else { echo 'Authentication failed for $username.'; } ?>
4、SQL注入问题
直接 SQL 命令注入就是攻击者常用的一种创建或修改已有 SQL 语句的技术,从而达到取得隐藏数据,或覆盖关键的值,甚至执行数据库主机操作系统命令的目的。这是通过应用程序取得用户输入并与静态参数组合成 SQL 查询来实现的。下面将会给出一些真实的例子。
<?php $query = "SELECT id, name, inserted, size FROM products WHERE size = '$size' ORDER BY $order LIMIT $limit, $offset;"; $result = odbc_exec($conn, $query); ?>
可以在原来的查询的基础上添加另一个 SELECT 查询来获得密码: union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable; 假如上述语句(使用 ' 和 –)被加入到 $query 中的任意一个变量的话,那么就麻烦了。
这些攻击总是建立在发掘安全意识不强的代码上的。所以,永远不要信任外界输入的数据,特别是来自于客户端的,包括选择框、表单隐藏域和 cookie。就如上面的第一个例子那样,就算是正常的查询也有可能造成灾难。
永远不要使用超级用户或所有者帐号去连接数据库。要用权限被严格限制的帐号。 检查输入的数据是否具有所期望的数据格式。PHP 有很多可以用于检查输入的函数,从简单的变量函数和字符类型函数(比如 is_numeric(),ctype_digit())到复杂的 Perl 兼容正则表达式函数都可以完成这个工作。
如果程序等待输入一个数字,可以考虑使用 is_numeric() 来检查,或者直接使用 settype() 来转换它的类型,也可以用 sprintf() 把它格式化为数字。
一个更安全的防止SQL注入的分页显示方法:
<?php settype($offset, 'integer'); $query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;"; $query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;", $offset); ?>
위 내용은 PHP 보안에 대한 지식을 정리했습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!