Web开发与运维安全浅见
Download as PPTX, PDF14 likes3,925 views
本文探讨了Web开发与运维安全，涵盖了SQL注入、文件上传、XSS、CSRF等安全漏洞及其防范措施。文档详细介绍了各种攻击方式和潜在的安全风险，以及如何合理保存和处理用户认证信息以确保安全。最后，还讨论了权限认证、数据存储及暴力破解等相关内容。
![当web是动态 ，后面有DB浏览器与服务器通过提交查询交互，最直观的以GET方式出现在URL的?后面的中的字符串参数，这些字符为DB语句的特殊字符，比如引号为SQL语句的闭合符号等。什么是SQL注入，如何注入例子: http://test.com/info.php?id=1 此URL返回数据库中，某表的第1条信息中的数据。程序中可能这么写的。$arrResult = mysql_query('SELECT * FROM table WHERE id = '.$_GET['id']); 如上的URL，那么查询语句将是SELECT * FROM table WHERE id = 1 如果URL是这样id=1 AND 1,那么查询语句将是SELECT * FROM table WHERE id =1 AND 1](https://image.slidesharecdn.com/web-110919213025-phpapp02/85/Web-30-320.jpg)
![filename :1234.php[\0].jpg,其中\0为十六进制的00当保存的时候，文件名的null字符之后的字符串将被舍弃，只保留前面的字符。那么，这个文件会被保存成一个php的文件。](https://image.slidesharecdn.com/web-110919213025-phpapp02/85/Web-40-320.jpg)
Web开发与运维安全浅见
- 2. 目录前置知识
- 3. SQL注入
- 4. 文件上传
- 5. XSS与SCRF
- 6. 远程文件包含
- 7. URL跳转
- 8. 权限认证
- 9. 数据存储与暴力破解
- 10. 文件解析
- 11. 其他前置知识Web的发展历程
- 13. 浏览器如何与服务端通信
- 14. 浏览器、传输协议、服务端
- 16. 传输协议 (http 1.0)
- 17. 服务端(iis、apache)
- 18. 与用户交互，新事物出现
- 21. 服务端如何与脚本语言通信
- 23. 保存用户提交的信息，新事物出现
- 24. 脚本语言如何与数据库通信
- 25. 更… …多的需求
- 30. 当web是动态 ，后面有DB浏览器与服务器通过提交查询交互，最直观的以GET方式出现在URL的?后面的中的字符串参数，这些字符为DB语句的特殊字符，比如引号为SQL语句的闭合符号等。什么是SQL注入，如何注入例子: http://test.com/info.php?id=1 此URL返回数据库中，某表的第1条信息中的数据。程序中可能这么写的。$arrResult = mysql_query('SELECT * FROM table WHERE id = '.$_GET['id']); 如上的URL，那么查询语句将是SELECT * FROM table WHERE id = 1 如果URL是这样id=1 AND 1,那么查询语句将是SELECT * FROM table WHERE id =1 AND 1
- 31. SQL注入URL变成如下这个 Info.php?id=1 AND SELECT LEFT(VERSION(),1) = ‘5’SQL语句将是SELECT * FROM table WHERE id =1 AND SELECT LEFT(VERSION(),1) = ‘5’可查询MYSQL版本的第一个字符是否是5原因是什么对提交的数据未过滤，产生SQL语句的拼接有哪些提交方式 GET、POST、COOKIE、其他如何防范
- 34. 字符串型参数：mysql_real_escape_stringSQL注入可能已有的防护依赖php.ini的magic_quotes_gpc，对提交的参数进行过滤，php会对单双引号、反斜杠、null等字符进行转移，我们不能依赖它，SQL注入的产生是SQL语句的拼接，安全问题是在SQL语句的执行，应该对进入SQL语句部分的参数进行SQL语句的转义，而不是PHP对字符串的转义，虽然转义字符看起来长得一样。同时，此参数的开启，对于需要用户原始输入的信息还需要做下反转义，比如用户密码(虽然不要保存原始的)其他间接的SQL注入 ECSHOP的URL参数部分是经过BASE64加密的，之后程序在base64解密完之后，直接使用解密的结果，不做过滤了。过分相信这些提交的参数，大部分情况，这些URL都是程序生成的。http://www.ecshop.cn/search.php?encode=YTo5OntzOjg6ImtleXdvcmRzIjtzOjE6IjEiO3M6ODoiY2F0ZWdvcnkiO3M6MToiMCI7czo1OiJicmFuZCI7czoxOiIwIjtzOjk6Im1pbl9wcmljZSI7czowOiIiO3M6OToibWF4X3ByaWNlIjtzOjA6IiI7czoxMDoiZ29vZHNfdHlwZSI7czoxOiIwIjtzOjY6ImFjdGlvbiI7czo0OiJmb3JtIjtzOjY6IlN1Ym1pdCI7czoxMjoi56uL5Y2z5pCc57SiIjtzOjE4OiJzZWFyY2hfZW5jb2RlX3RpbWUiO2k6MTMxNjIyODE3MDt9
- 35. SQL注入其他间接注入 一些网页游戏，前端FLASH与后端脚本通讯时，选择使用AMF之类协议，也是有前端(flash)将提交查询的SQL语句加密之后，发送给后端程序，后端程序解密，再做相关查询。这个流程中，也是漏掉对解密的参数继续做过滤判断。
- 36. SQL注入
- 37. SQL注入
- 40. filename :1234.php[\0].jpg,其中\0为十六进制的00当保存的时候，文件名的null字符之后的字符串将被舍弃，只保留前面的字符。那么，这个文件会被保存成一个php的文件。
- 42. PNG(8 bytes):89 50 4E 47 0D 0A 1A 0A
- 43. GIF(6 bytes):47 49 46 38 39 61 (GIF89a)
- 45. PHP GD库重绘图片
- 47. 文件名不使用原文件名，随机生成
- 49. XSS与CSRF什么是XSSCross Site Scrip 跨站脚本攻击主要分两类
- 50. 来自“站内”
- 51. 来自外部提交比如URL是这个 1.php?keyword=<script>alert(document.cookie)</script>脚本中代码这么写echo '<tr><td>',$_GET['keyword'],'</td></tr>';有何危害 执行任意JS代码。最常见的做法是获取COOKIE认证信息；其他的就是跳转至恶意网址等，或者配合CSRF漏洞，进行创建form表单，进行提交，强制使当前用户操作，比如发帖，删帖，甚至转账等。
- 52. XSS与CSRF什么是CSRFCross-site request forgery跨站请求伪造如何产生的CSRF利用的前提是XSS，但可以是其他网站的，需要确定用户都在同一浏览器访问了他们。如何防护
- 55. 验证码：用户体验差
- 60. 区别：保存方式、回收者不一样。
- 62. 权限认证Session如何被劫持的，为什么攻击者先访问网站，获得一个SESSION ID,如果此网站的session传递用的是URL方式，那么将此URL发送给对方，比如http://test.com/index.php?PHPSESSID=sadas2asds2a。如果此网站使用的是cookie存储session id，可以利用XSS漏洞，让JS设置对方的COOKIE中PHPSESSID为攻击者的PHPSESSID。当对方登录之后，认证通过，程序将用户信息写入到session id为URL参数的PHPSESSID的值的文件中。攻击者也使用这个session id继续访问的时候，由于这个session id中也是被攻击用户的认证信息，则认为这个攻击者也是被攻击用户。产生劫持。原因你或许会说，为什么程序认为他是同一个用户呢，他们并不是同一个用户，他们不一样。没错，他们是不一样，正是程序没有验证他们不一样的地方，所以才出现这种情况。不一样的地方比如浏览器的user-agent，IP或者他。权限认证如何防范COOKIE欺骗与SESSION劫持
- 67. 他们保存的认证信息的安全最重要。
- 68. 如何选择
- 75. 数据库被窃取，还原用户密码一些网站会明文保存用户密码，对于这种，攻击者无需还原。多数网站会加密存储用户密码，即使数据库泄漏，恶意攻击者也需要一定的时间，精力去组合密码，加密之后与用户密码对比，确定是否正确。暴力破解与数据传输用户密码保存用户密码从最初的明文保存到后来的MD5 加密一次，到二次加密，以及discuz的 salt做法比较常见，对于彩虹表来说，这些或许都可以直接从彩虹表内查出原来的明文密码。建议取当前用户不变的信息进行变换，移位等方式加密。比如md5(user+md5(pass)+salt+系统密钥)，甚至类似身份证算法，根据用户名以及salt的字符组合，计算生成一个字符，之后到密钥里取出一个字符串，放入计算的密码中，生成密码MD5 hash字符串。这样密码的安全需要用户名、用户密码、密钥字符串、系统分配的SALT、权字符算法等五个因素生成。增加了攻击者获取原始密码的难度等等。$sQ = getQuan($user,md5($pass),$sSalt);$sT = getT($sQ,$sKey);$sMd5pass = md5($user,md5($pass),$sSalt,$sT,$sKey);
- 85. 文件解析nginx与phpcgi通信采用CGI协议，发送服务器环境变量，当前域名、端口，客户端IP、端口、提交HTTP数据包的代理软件信息，HTTP包内容等；还包括当前请求的URI，QUERY_STRING、SCRIPT_FILENAME、SCRIPT_NAME、 PATH_INFO等信息通过CGI协议，STDIN交给后端PHP CGI，PHP CGI根据nginx提交来的信息，再进行解析操作。这里，PHP CGI是绝对相信NGINX提供的信息的，不管NGINX提交来的是什么，PHP CGI都会去当作php脚本来解析。
- 89. PATH_INFO=> //空，根据正则，没匹配到
- 93. foo.php将变成PATH_INFO，便按照PHP解析。文件解析问题处在哪里？NGINX是按照配置文件进行匹配URI，获得SCRIPT_NAME以及PATH_INFO；PHP也是按照NGINX通过CGI协议传递的环境变量进行解析的。web server跟cgi脚本都没错，错是错在nginx配置文件内匹配的URI的正则表达式，以及php.ini内的cgi.fix_pathinfo再次的解析了SCRIPT_FILENAME。解决办法关闭php.ini的cgi.fix_pathinfo配置项，或者if ( $fastcgi_script_name ~ \..*\/.*php ) {return 403;}此方法虽然可以屏蔽这个漏洞的发生，但一定程度上影响了正常的业务需求，比如这个URI “1.php/test/a.php?a=1”是合法的URI，却被阻止了。比如CodeIgniter、ThinkPHP等框架，这个方法将不适合。
- 95. 文件解析解析漏洞发生的条件
- 97. 存在错误解析的漏洞
- 98. 如何防范
- 102. 按照程序开发习惯，目录命名中基本没有.这个字符；出现在URI中的文件名的中基本不会出现两个.这个字符。所以我给出的解决办法就是认为URI中出现的第一个.后面的拓展名是php的时候，才会交与php-cgi解析(当然，要先取出SCRIPT_NAME、PATH_INFO)。其他弱口令、空口令redis、memcache等之类nosql默认不验证或者没验证，依赖操作系统进行访问控制。对于使用session保存会话，且将session保存至这些nosql中的话，无意是致命的，务必要有访问控制。掩耳盗铃if (!(is_admin($arrAuth))) { echo '<script>document.location.href="./"</script>';}if (!(is_admin($arrAuth))) { header("Location:http://test.com/login.php");}// 验证通过。。