有关Web 安全学习的片段记录（不定时更新）

很多Web 安全漏洞的产生原因都绕不开两条：

1.违背了“数据与代码分离“原则。它有两个条件：一是用户能够控制数据的输入；二是代码拼凑了用户输入的数据，把数据当作代码执行了。

2.违背了权限管理的黄金法则：最小权限原则。

一、有关html/css, js, php, cgi 的一些认识

 

selector 常见的就 type, class(.), id(#)，注意的是 id 只能一个页面一个。

e.g

在html 中引入css 一般有以下3种方式：

  ---行内式

  

---链入外部样式表文件 (Linking to a Style Sheet)

Remember, HTML will define the content and structure of our web pages, while CSS will define the visual style and appearance of our web pages.

还有一些其他类似的文件类型，如 shtml, phtml, jhtml，这类可以算是动态网页，比如 shtml (ssi)可以 引入一个html，服务器会将其解析并填充在返回的页面中；phtml 即源码包含 语句；jhtml 源码包含 jsp <% %> 语句。

       当我们浏览器访问一个站点的静态文件，会把文件内容都下载下来（一般压缩），当然如果遇到外联的css/js，会再发起请求得

到。如果我们右键查看网页源代码，一片混乱没法看，可以使用firefox + firebug，可以清晰看到html dom tree，右键inspect 

element 可以很快定位到tree node，由于是下载到本地，所以可以自己尝试修改element 查看效果，这并不影响服务器上的原始

文件。最后浏览器会开始渲染，包括执行js比如document.write() 之类，就呈现出现在我们所看到的网页模样，可以使用firefox F12 断点调试js。

所谓的 dom 树操作就是一系列类似 getElementById 之类的函数。注意 js 是在客户端执行的，可以动态地改变 dom 树，通俗地说就是可以改变页面

的html，人们从浏览器看见的页面也就变化了。

html 的解析顺序：html parser --> css parser -->javascript parser

CGI 的意思是啥？不是一种语言，也不是一种技术，而是一种模式。搜索一下CGI的定义Common Gateway Interface，简称CGI。在物理上是一段程序，存放在服务器上。只要是提供数据输出的服务器端程序都可以叫CGI，ASP/PHP/JSP这些都可以认为是，你用C/C++写一个可以提供数据输出的服务器端bin文件，也叫CGI，至于python/perl/shell 等脚本当然也能写cgi。

对一个 CGI 程序，做的工作其实只有：从环境变量(environment variables)和标准输入(standard input)中读取数据、处理数据、

向标准输出(standard output)输出数据。环境变量中存储的叫 Request Meta-Variables，也就是诸如 QUERY_STRING、

PATH_INFO 之类的东西，这些是由 Web Server 通过环境变量传递给 CGI 程序的，CGI 程序也是从环境变量中读取的。

标准输入中存放的往往是用户通过GET 或者 POST 提交的数据，这些数据也是由 Web Server 传过来的（客户端提交）。传统的

get 即是以 url?key1=value1&key2=value2的 形式传输过去。而post 形式（http请求包体）就比较多了，可以是传统的

key=value，也可以是json/xml 等形式，只是这些从标准输入得到后还需要经过一个解析的过程才能得到想要的key=value 形式的呈现。

注意标准输入的概念，如果在本地执行 php xx.php args  那些 xx.php 的标准输入就是控制命令窗口，获取输入需要通过 $argv；如果是通过 uri 路径访问 xx.php 如 http://localhost/xx.php，那么 xx.php 的标准输入来自 webserver 给的数据，可以通过 php://input 获取。

当然cgi 的body输出也是多种形式了，可以是简单的application/json、text/xml 形式，也可以是php echo 出一个text/plain or text/html，但要明确的是php 等脚本是在服务器端执行的，也就是说当客户端访问test.php 时，server 先执行php脚本（php 会 读取标准输入，处理过程，向标准输出输出数据），形象地来说，就是“戳一次就动一次”，根据用户输入的不同而产生不同的输出结果，即动态网页的概念。注意，php, js css, 都可以和html 标签写在同个文件中。

有时候访问出现403 forbidden ，有种原因是 apache 设置的user，即运行httpd的user 是nobody（假设），对你想要访问的目

录/文件 没有读或者执行的权限，所以server 没办法读取执行文件，故 禁止访问。还有种情况是配置文件写明 deny xxx，禁止某些来源ip 访问，或者

禁止访问某些目录、某种后缀的文件。

二.   各种编码、转义相关

从浏览器 url发出的请求，如果进行了 urlencode（比如chrome一般会编码 "<>，firefox 一般会编码 ' " `<>， 而低版本 ie 不会编码任何字符），比

如将 " 转成%22 发出去，在服务器端的php 接收到的是原始的" 还是编码后的%22 得看用$_GET["key"] 还是$_SERVER['QUERY_STRING']，还要看

在php 脚本内有没有做addslashes 或者 htmlspecialchars 等函数调用，这样就能判断解析脚本 echo/print 出来的html 是怎样的组织形式，当然客

户端请求得到的html 也就是这样的形式了。那为什么在chrome中对于< 等没有alert 弹窗呢，只是因为某些浏览器有anti_xss 模块或者filter，在浏览

器解析 html 的时候 过滤掉这些危险的script 而没有执行，比如 ie 可以关闭掉 xss 筛选器让其弹框。

对于低版本 ie 而言，如果页面 js 取location.href or #锚参数 or  &get参数 的值，则保持 地址栏原有模样。而高版本 ie 或者 其他浏览器 取到的都是

编码后的样子（取决于浏览器本身会编码哪些字符发起请求）。这对于 domxss 来说是一个比较重要的区分点。需要注意的是 chrome：

http://www.foo.com/dom/loc.html? -- 编码

http://www.foo.com/dom/loc.html# -- 不编码

为了看参数是否Urlencode对返回结果是否有影响，可以用一些工具比如 fiddle 发出编码和不编码时的请求，对比观察。

这种不编码访问才能触发的xss 漏洞，最简单的利用方式是写一个html，里面用 iframe src 引入完整不编码 payload 链接，用 ie 访问此 html。

注意如果此时弹 cookie 的话弹出的是 iframe 内 domain 域的 cookie，因为浏览器在请求第三方站点时也会把相关cookie发送出去（没有P3P 属性

的 persistent cookie 有例外），如下：