【译】发送表单数据

Hi Mom

例子&＃xff1a;原生Python

本例子使用Python实现相同的功能--显示网页提供的数据。例子中使用CGI Python package来获取数据。

#!/usr/bin/env python
import html
import cgi
import cgitb; cgitb.enable() # for troubleshootingprint("Content-Type: text/html") # HTTP header to say HTML is following
print() # blank line, end of headersform &＃61; cgi.FieldStorage()
say &＃61; html.escape(form["say"].value);
to &＃61; html.escape(form["to"].value);print(say, " ", to)

显示结果和上面的例子一样&＃xff1a;

Hi Mom

其他语言和框架

还有许多其他的服务端技术可以处理表单&＃xff0c;包括Perl,Java,.Net,Ruby等等。选择你最喜欢的就好了。但是也没有必要直接使用这些技术去处理表单&＃xff0c;因为会比较繁琐。更通常的做法是选择一种框架来辅助处理表单&＃xff0c;比如&＃xff1a;

• Symfony for PHP
• Django for Python
• Ruby On Rails for Ruby
• Grails for Java

虽然使用这些框架来处理表单不一定就是非常容易&＃xff0c;但是总是好一些&＃xff0c;并且可以节省大量时间。

一种特殊情况&＃xff1a;发送文件

发送文件对表单来说是一种特殊情况。文件是二进制数据--至少被当作二进制数据--但是其他数据都是文本数据。因为HTTP协议是一种文本协议&＃xff0c;所以处理二进制数据是特殊需求了。

enctype属性

该属性可以指定Content-Type字段的值。该字段非常重要&＃xff0c;因为可以让服务器端识别出发送的数据类型&＃xff08;编码类型&＃xff09;。默认值是application/x-www-urlencoded。对人类而言&＃xff0c;这意味着&＃xff1a;“表单数据已经被编码成URL形式了”。

如果我们想要发送文件&＃xff0c;应该需要做两件事&＃xff1a;

1. 设置method属性为POST&＃xff0c;因为文件内容不能放到URL中。
2. 设置enctype属性为multipart/form-data&＃xff0c;这样文件会被分割成很多部分发送到服务器。

举个例子&＃xff1a;

Send the file


注意&＃xff1a;有些浏览器的input元素支持multiple属性&＃xff0c;从而支持一个input元素可以发送多个文件。服务器端怎样处理这些文件完全依赖与服务器端选择的技术。前面也提到过&＃xff0c;使用框架来处理这些东西会稍微轻松些。

警告&＃xff1a;许多服务器都限制了上传文件的大小和HTTP请求的大小&＃xff0c;以防止滥用资源。和服务器管理员确定这个限制的大小是非常重要的。

安全问题

当你每次发送数据给服务器时&＃xff0c;你都应该考虑安全问题。HTML表单是服务器的主要威胁之一。不过问题并不是来源于表单本身&＃xff0c;而是服务器如何处理表单数据。

常见安全漏洞

以下是一些众所周知的安全问题&＃xff1a;

XSS和CSRF

跨站点脚本攻击&＃xff08;XSS&＃xff09;和跨站点请求伪造&＃xff08;CSRF&＃xff09;是常见的攻击类型&＃xff0c;这通常发生在服务器接收用户的数据然后再次显示这些数据给用户。

XSS使得攻击者可以注入客户端脚本到网页中。一个XSS漏洞可能会让攻击者可以绕过访问控制&＃xff0c;比如同源策略。这些攻击的影响可大可小&＃xff0c;可以是比较小的干扰&＃xff0c;也可以是重大安全风险。

CSRF和XSS有些相似--因为他们都需要注入客户端脚本到网页中--但是CSRF的目的又不一样。CSRF攻击者会提升自己的特权&＃xff08;比如网站管理员&＃xff09;&＃xff0c;然后就可以做一些本来没有权利的操作&＃xff0c;比如发送数据给不信任的用户。

XSS攻击利用用户对网站的信任&＃xff0c;CSRF攻击利用网站对用户的信任。

为避免这些攻击&＃xff0c;你应该检查用户发送到服务器的所有数据&＃xff0c;而且不应该显示用户提供的HTML内容。相反&＃xff0c;你应该处理这些数据而不是一字不变的显示这些数据。如今大部分框架都实现了基本的HTML字符过滤&＃xff0c;比如过滤掉,,。这可以降低风险&＃xff0c;但还是不能完全避免掉。

SQL注入

SQL注入是一种尝试操作网站数据库的一种攻击。攻击者通常会发送SQL请求并期望服务器去执行它&＃xff08;其实就是存储数据&＃xff09;&＃xff0c;这也是服务器的主要威胁之一。

这种攻击的后果是非常严重的&＃xff0c;轻一点就是数据丢失&＃xff0c;严重的就是特权提升到可以操作所有服务器资源。这种威胁是非常严峻的&＃xff0c;所以你永远不应该直接存储用户提交的数据&＃xff0c;而是需要做一些检查以及消毒工作&＃xff08;比如在PHP/MySQL应用中使用mysql_real_escape_string()&＃xff09;。

HTTP header注入 以及 email 注入

如果你使用表单数据来建立HTTP header或者email&＃xff0c;那么就有可能发生这些攻击。他们不会直接攻击服务器或者影响到用户&＃xff0c;但却是更深层次问题的后门&＃xff0c;比如会话劫持或者钓鱼攻击。

这些攻击大部分都是静悄悄的&＃xff0c;但是却会将你的服务器变为肉鸡。

警记&＃xff1a;永远不要相信你的用户

那么怎样处理这些威胁呢&＃xff1f;这些内容已经超出本章内容了&＃xff0c;但是仍然有一些规则需要牢记在心中。最最重要的规则就是&＃xff1a;永远不要相信用户&＃xff0c;包括自己&＃xff1b;因为一个可信任的用户也可能被劫持。

所有到达服务器的数据都需要检查和消毒&＃xff0c;总是这样做&＃xff0c;不要存在例外。

• 转义潜在的危险的字符。根据数据内容的不同以及部署平台的不同&＃xff0c;需要小心的字符也有所区别。但是所有服务器端语言都有相关的函数来处理这种转义。
• 限制数据的大小以及必须的类型。
• 上传文件到沙箱&＃xff08;存储这些文件到一个不同的服务器&＃xff0c;而且只允许通过一个不同的子域名来访问文件&＃xff0c;甚至最好是完全不同的域名来访问文件&＃xff09;。

如果你遵守上面三条规则&＃xff0c;你应该可以避免掉绝大部分的难题了&＃xff0c;但是邀请第三方做一个安全审查仍然是一个好主意。永远不要假设你已经解决了所有问题。

总结

如你所见&＃xff0c;发送表单数据是非常容易的&＃xff0c;但是只做安全的web应用则是复杂的。要记住作为前端开发者不仅仅只是定义数据模型。我们还要做客户端的数据校验&＃xff0c;但是服务器端仍然不能信任这些校验结果&＃xff0c;因为服务器可没办法知道客户端的真实情况。

另请参见

下面两个链接是关于安全web应用方面的&＃xff0c;可以继续参考学习&＃xff1a;

1. The Open Web Application Security Project (OWASP)
2. Chris Shiflett&＃39;s blog about PHP Security

下面是关于http方面的链接

1. GET/POST之enctype
2. GET vs. POST
3. What&＃39;s the difference between “Request Payload” vs “Form Data” as seen in Chrome dev tools Network tab
4. How are parameters sent in an HTTP POST request?

个人补充

上面更多的内容是关于web安全方面的&＃xff0c;下面补充一点method以及enctype方面的信息。

表单中method属性用来指定发送数据的方法&＃xff1a;比如GET/POST/PUT等等
表单中enctype属性用来指定发送的数据的编码方式&＃xff1a;比如text/plain,application/json,application/x-www-form-urlencoded,application/octet-stream,multipart/form-data等等

GET/POST/PUT最大的不同当然是语义不一样&＃xff0c;不过这里只研究对于发送数据的影响。
GET发送的数据位于URL中的query string部分&＃xff0c;而URL又处于请求header部分。
POST/PUT发送的数据位置倒是一样&＃xff0c;都是位于请求body部分。

不同的method会影响到发送数据的位置&＃xff0c;而enctype则会影响到数据的编码方式。
form元素的enctype默认值则是application/x-www-form-urlencoded&＃xff0c;所以发送的数据可能长得像这样&＃xff1a;

username&＃61;name123&password&＃61;pass456&age&＃61;12&sex&＃61;1

注意这种编码形式和GET/POST/PUT是没有关系的。只不过如果是GET方法&＃xff0c;那么URL加上问号&＃xff08;&＃xff1f;&＃xff09;再加上数据拼接起来。如果是POST/PUT方法&＃xff0c;那么数据就存放在请求body部分。

对于jquery中的ajax方法的contentType默认值也是application/x-www-form-urlencoded。
而在backbone中&＃xff0c;Backbone.sync方法中有一段代码会做出判断&＃xff0c;可能会将contentType设置为application/json。

先说说multipart/form-data&＃xff0c;一般在上传文件的时候&＃xff0c;需要将表单的enctype设置为multipart/form-data。正如上面译文中所讲&＃xff0c;文件属于二进制数据&＃xff0c;application/x-www-form-urlencoded是不适用的。
不过这种编码方式过于复杂&＃xff0c;不像上面的urlencoded编码&＃xff0c;只需要两次分割字符串就能得到所有的键值对。对于这种复杂的编码方式&＃xff0c;我们自己去解析数据&＃xff0c;是很难的&＃xff0c;幸好已经有开源的库完成了这一部分功能。
对于单文件上传也许还好&＃xff0c;自己了解编码方式以后&＃xff0c;解析起来也不是很难。难点在于多文件上传&＃xff0c;甚至还有普通表单控件混在其中。

再说说application/json&＃xff0c;据我理解urlencoded编码方式只适用于扁平化的键值对&＃xff0c;对于嵌套过深的json对象就很难编码了。而application/json就非常适用于嵌套过深的json数据。
在chrome的开发者工具中的network页签中&＃xff0c;显示发送数据位于Request Payload。而如果是application/x-www-form-urlencoded&＃xff0c;就会显示发送数据位于Form Data。

实际上是可以自定义contentType的&＃xff0c;也就是自定义编解码的规则。不过只针对ajax有效&＃xff0c;对于form元素是不起作用的。因为form元素的编码规则有浏览器控制。而对于ajax&＃xff0c;我们完全可以自己编码&＃xff0c;然后在服务器端自己解码。

最后一点&＃xff0c;如果服务器端不能理解Content-Type指定的编码方式&＃xff0c;那么应该返回415错误。