相关web 片段记录安全性研究（不时更新）

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

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

到。假设我们右键查看网页源码。一片混乱没法看，能够使用firefox + firebug，能够清晰看到html dom tree。右键inspect

element 能够非常快定位到tree node。因为是下载到本地，所以能够自己尝试改动element 查看效果，这并不影响server上的原始

文件。最后浏览器会開始渲染，包含运行js比方document.write() 之类。就呈现出如今我们所示网页模样。能够使用firefox F12 断点调试js。

CGI 的意思是啥？不是一种语言。也不是一种技术。而是一种模式。搜索一下CGI的定义Common
Gateway Interface，简称

CGI。在物理上是一段程序，存放在server上。

仅仅要是提供HTML的server端程序都能够叫CGI，ASP/PHP/JSP这些都能够觉得是。你用C/C++写一个能够提供HTML的server端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 传过来的（client提交）。传统的

get 即是以 url?

key1=value1&key2=value2的 形式传输过去。

而post 形式（http请求包体）就比較多了。能够是传统的

key=value。也能够是json/xml 等形式。仅仅是这些从标准输入得到后还须要经过一个解析的过程才干得到想要的key=value
形式的

呈现。

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

有时候訪问出现403 forbidden ，有种原因是 apache 设置的user。即执行httpd的user 是nobody（如果），对你想要訪问的目

录/文件 没有读或者运行的权限，所以server 没办法读取运行文件，故 禁止訪问。

还有种情况是配置文件写明
deny xxx，禁止某些来源ip 訪问。

二.   各种编码、转义相关

从浏览器 url发出的请求。假设进行了 urlencode（比方chrome通常会 urlencode 而 ie 不会，一般copy而来的url会被encode），比方将 " 转

成%22 发出去。在server端的php 接收到的是原始的" 还是编码后的%22 得看用$_GET["key"] 还是$_SERVER['QUERY_STRING']，还要看在php 脚

本内有没有做addslashes 或者 htmlspecialchars 等函数调用，这样就能推断解析脚本 echo/print
出来的html 是如何的组织形式，当然客户端请求

得到的html 也就是这种形式了。那为什么在chrome中对于<
等没有alert 弹窗呢，仅仅是由于某些浏览器有anti_xss 模块或者filter，在浏览器解析

html 的时候 过滤掉这些危急的script
而没有运行。

htmlspecialchars 会把 < 编码成 &lt; 还有 >,",' 等

addslashes() 函数在指定的提前定义字符前加入反斜杠。这些提前定义字符是：

单引號 (')

双引號 (")

反斜杠 (\)

NULL

这样就无法从url 传递带引號的參数来闭合引號来达到xss的目的。可是在charset=gbk 的情况下。假设參数含大于

127的值如%ae，后面再跟引號，尽管引號变成\', 但%ae\ 在gbk 看来或许是一个字符，当然我们看起来好像是一个

乱码，这样也会造成引號能够闭合，sql 注入也存在这种字符集解析问题。设置了某种字符集，浏览器会按这种编

码去解析html 来展示给用户。(memchr)

尽管大部分浏览器不会解析 Content-type: application/plain 响应头下的 body。但如 safari 以及某些版本号的ie 都可能不按套路行事。在一些不须要html 解释的页面，能够通过设置Content-type:application/json
来避免 xss。

反斜杠 \ 在script域内会起转义作用。而在html 标签内就是表示的字符含义，从以下alert()出来的字符能够得知。

<script> var test="a\""; alert(test); </script>

<script> var test='a\''; alert(test); </script>

<script> var test='a';   alert(test); </script>

<input type="text" value="a\" onmousemove=alert(/xss/) " />

三.  登录跳转、登录验证

一般站点登录前的验证可能是这样实现的：

<form action="processs.php", id="login" method="post" onsubmit="return validate();">

在用户填完信息后会先调用validate() 函数进行验证，假设返回true 才会真正提交表单。

在validate() 里类似 if(document.forms.login.agreement.value != checked) { return false;}

// document.getElementById("login").agreement.value id 必须全局唯一

在不想重载页面。也就是不提交，能够 onsubmit="quote(); return false;" 在quote()里面能够 xhr= new XMLHttpRequest();

即ajax的方式来做一些操作。

一般的站点登录跳转实现方式之中的一个是：在login.php 对表单post 过来的user&pwd&email 验证(见以下），假设对则设置一个键值如 $_SESSION["auth"]=true。设置response
的Location Head : home.php，本程序exit。浏览器接收到rsp，看到Location 头部，于是跳转请求至home.php。

home.php 能够对$_SESSION["auth"]
继续推断一次。若true 则显示登录后的页面。当然这一切的前提是login.php开启了session_start()，这样第二次訪问home.php 也会带上Cookie:PHPSESSID=xxx
，这样server 通过 $_COOKIE 获取sessionId就知道是同个用户的请求，通过sessionId
就能够知道 $_SESSION 结构体中原本存放的数据，比方auth=True 之类。

superglobals : $_COOKIE  $_ENV  $_FILES  $_GET  $_POST $_REQUEST $_SERVER $_SESSION

实际上带登录态的漏洞扫描也是带上cookie 实现的，须要注意cookie失效的问题。一般server对每一个网页请求会做登录验证。经常使用两种方式：

1）. 从cookie头中获取sessionId，进而从server 端存储的Session信息中获取相关验证信息。如user&pwd&email之类，与post过来的信息进行比对（可能须要依据post数据字段查数据库），验证通过则显示请求的网页，否则跳转到登录页面。

Session 的长处是简单易用，能够直接从Session中取出用户登录信息。

Session 的缺点是server须要在内存中维护一个映射表来存储用户登录信息，假设有两台以上server就须要对Session 做集群。因此使用Session的Web App 非常难扩展。

比方 web.py 框架中 session.py 有：

'cookie_name': 'webpy_session_id' // 定义

self.session_id = web.cookies().get(cookie_name) // server 获取sessionId

self._setcookie(self.session_id) // server 设置Client 的cookie。Set-Cookie 头，即调用以下的函数

web.setcookie(cookie_name, session_id, expires=expires, domain=cookie_domain, httponly=httponly, secure=secure, path=cookie_path)

self.store[self.session_id] = dict(self._data) // server 端存储session_id 相关的用户数据

2). 先直接依据post 过来的数据字段查数据库进行比对，但此时还须要验证cookie 不是伪造的。实现防伪造cookie的关键是通过一个单向算法

（比如MD5）。举比例如以下：

当用户输入了正确的口令登录成功后，server能够依据post数据从数据库取到用户的id，并依照例如以下方式计算出一个字符串：



"用户id" - "过期时间" - MD5("用户id" + "用户口令" + "过期时间" + "SecretKey")



并通过set-cookie 设置浏览器的cookie。

当浏览器发送cookie 到server端后。server能够拿到的信息包含：用户id、过期时间、MD5值



假设未到过期时间。server就依据用户id 查找用户口令，并计算：

MD5("用户id" + "用户口令" + "过期时间" + "SecretKey")

并与浏览器cookie中的MD5 进行比較。假设相等则说明用户已登录，否则cookie就是伪造的。

这个算法的关键在于MD5是一种单向算法。即能够通过原始字符串计算出MD5，但无法通过MD5反推出原始字符串。

四、session, token, cookie的差别与联系

1. 因为HTTP协议是无状态的协议。所以服务端须要记录用户的状态时，就须要用某种机制来识详细的用户，这个机制就是Session.典型的场景比方购物车。当你点击下单button时，因为HTTP协议无状态。所以并不知道是哪个用户操作的，所以服务端要为特定的用户创建了特定的Session。用用于标识这个用户，而且跟踪用户，这样才知道购物车里面有几本书。这个Session是保存在服务端的，有一个唯一标识sessionId。在服务端保存Session的方法非常多，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的站点，通常会有专门的Sessionserver集群，用来保存用户会话。这个时候
Session 信息都是放在内存的。使用一些缓存服务比方Memcached之类的来放 Session。

一般会话Session随着会话cookie删除而删除，而持久型Session信息会永久保存，尽管会随着持久型cookie的失效而无用。



2. Session cookie

A session cookie, also known as an in-memory cookie or transient cookie, exists only in temporary memory while the user navigates the website.When an expiry date or validity interval is not set at cookie creation time, a session cookie is created. Web browsers
normally delete session cookies when the user closes the browser.

思考一下服务端怎样识别特定的客户？这个时候Cookie就登场了。每次HTTP请求的时候，client都会发送对应的Cookie信息（如 Cookie:
PHPSESSID=xxxxx;）到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉client。须要在 Cookie 里面记录一个Session ID（Examples of the names
that some programming languages use when naming their cookie include JSESSIONID (JEE), PHPSESSID (PHP), and ASPSESSIONID (Microsoft ASP).），以后每次请求把这个会话ID发送到server。我就知道你是谁了。有人问，假设client的浏览器禁用了 Cookie 怎么办？一般这样的情况下。会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx
这种參数，服务端据此来识别用户。

会话cookie: 是一种暂时的cookie，它记录了用户訪问网站时的设置和偏好，关闭浏览器，会话cookie就被删除了。



3.Persistent cookie

A persistent cookie outlasts user sessions. If a persistent cookie has its Max-Age set to one year (for example), then, during that year, the initial value set in that cookie would be sent back to the server every time the user visited the server. This could
be used to record a vital piece of information such as how the user initially came to this website. For this reason, persistent cookies are also called tracking cookies.

持久型cookie 一般用来保存一些少量信息，如当初用户是从哪个url 跳转来的。

持久cookie: 存储在硬盘上。（无论浏览器退出，或者电脑重新启动，持久cookie都存在）， 持久cookie有过期时间。



所以。总结一下：

Session是在服务端保存的一个数据结构，用来跟踪用户的状态。这个数据能够保存在集群、数据库、文件里；

Cookie是client保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。



client :  

Cookie: name=value; name2=value2               



server:

Set-Cookie: LSID=DQAAAK…Eaem_vYg; Path=/accounts; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly

Set-Cookie: HSID=AYQEVn….DKrdst; Domain=.foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; HttpOnly

Set-Cookie: SSID=Ap4P….GTEq; Domain=foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly

Domain 和 Path 决定浏览器在訪问此网站某文件夹下的网页时cookie 才会被发送出去。Expires 确定cookie的过期时间，没有过期时间则为session

cookie，有则是persistent cookie。

Secure 表示仅仅有通过https 连接才会发送cookie。HttpOnly 表示仅仅有通过http 訪问才会发送cookie，比方在client

运行js: document.cookie 是获取不到cookie的。

桌面应用程序也通过HTTP协议跟Webserver交互， 桌面应用程序一般不会使用cookie, 而是把 "username+冒号+password"用BASE64 编码的字符串放在http request 中的header Authorization 中发送给服务端， 这样的方式叫HTTP基本认证(Basic Authentication)

在chrome浏览器里能够用 http://username:password@url这样的方式直接略过这个基本认证

版权声明：本文博主原创文章，博客，未经同意不得转载。