CGI 回显 POST 数据 - 安全问题？
CGI echoes POST data - security issue?
我想使用 JavaScript 在网站上生成一个文件并提供给用户下载。我了解到使用普通 JavaScript 和 HTML5.
是不可能的
我正在考虑将生成的文件内容发布到我的服务器上的一个 CGI 函数，该函数只是回显数据。通过设置正确的headers我可以这样提供数据下载
我想知道这样的 echo CGI 函数是否会被滥用并导致安全问题。该网站（也是 CGI 功能）使用基本身份验证进行密码保护。
有意见吗？
如果它只是回显来自客户端的数据，我看不出有任何安全问题。客户已经知道该数据。您只是更改 headers 以便浏览器允许您将内容保存为文件。
您不会向尚未获得访问权限的各方披露任何信息。
是indeed possible to do this using data: URLs:
<a href="data:application/octet-stream;charset=utf-16le;base64,//5mAG8AbwAgAGIAYQByAAoA">text file</a>
但是，如果您仍希望使用 CGI 方法，则允许页面回显 POSTed 数据存在安全风险。这被称为 reflected Cross Site Scripting (XSS)。
假设您有一个 CGI 监听 https://example.com/cgi-bin/downloader。
假设用户已经通过您的基本身份验证进行了身份验证，然后收到一封包含 link 的电子邮件。用户访问电子邮件中的网站（比如 evil.com），它创建了一个 JavaScript 提交给 https://example.com/cgi-bin/downloader 的 POST 请求，其中包含一个 HTML 文档，其中还包含一些JavaScript 将 cookie 从您的域发送给攻击者。即使您设置正确的 content-type header 以将 HTTP 响应识别为 XML、some browsers (IE) will try to sniff the content 并向用户呈现浏览器认为的内容类型（HTML 在这种情况下）。为避免这种情况，请确保在响应中设置以下 header：
X-Content-Type-Options: nosniff
因此，在响应中将此 header 与内容类型 text/xml 结合使用应该可以降低 XSS 的风险。我还建议设置 Content-Disposition header，这样文件将被下载而不是显示：
Content-Disposition: attachment; filename="bar.xml"
为了首先阻止其他站点向您的 CGI 服务发出请求，您可以使用 CSRF prevention 方法。推荐的方法是“Synchronizer Token Pattern”，这涉及创建一个绑定到用户 session 的服务器端令牌，该令牌必须与 POST 请求一起提交。使用基本身份验证的系统是否可以做到这一点由您决定。可以使用 Referer header，尽管这不太安全：
checking the referer is considered to be a weaker form of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check and some organizations or browser tools remove referrer headers as a form of data protection. There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.
In short, referer checking is a reasonable form of CSRF intrusion detection and prevention even though it is not a complete protection. Referer checking can detect some attacks but not stop all attacks. For example, if you HTTP referrer is from a different domain and you are expecting requests from your domain only, you can safely block that request.
您还应该对此进行测试以确保 script will not be executed when an XML is downloaded using Internet Explorer.
我想使用 JavaScript 在网站上生成一个文件并提供给用户下载。我了解到使用普通 JavaScript 和 HTML5.
是不可能的我正在考虑将生成的文件内容发布到我的服务器上的一个 CGI 函数，该函数只是回显数据。通过设置正确的headers我可以这样提供数据下载
我想知道这样的 echo CGI 函数是否会被滥用并导致安全问题。该网站（也是 CGI 功能）使用基本身份验证进行密码保护。
有意见吗？
如果它只是回显来自客户端的数据，我看不出有任何安全问题。客户已经知道该数据。您只是更改 headers 以便浏览器允许您将内容保存为文件。
您不会向尚未获得访问权限的各方披露任何信息。
是indeed possible to do this using data: URLs:
<a href="data:application/octet-stream;charset=utf-16le;base64,//5mAG8AbwAgAGIAYQByAAoA">text file</a>
但是，如果您仍希望使用 CGI 方法，则允许页面回显 POSTed 数据存在安全风险。这被称为 reflected Cross Site Scripting (XSS)。
假设您有一个 CGI 监听 https://example.com/cgi-bin/downloader。
假设用户已经通过您的基本身份验证进行了身份验证，然后收到一封包含 link 的电子邮件。用户访问电子邮件中的网站（比如 evil.com），它创建了一个 JavaScript 提交给 https://example.com/cgi-bin/downloader 的 POST 请求，其中包含一个 HTML 文档，其中还包含一些JavaScript 将 cookie 从您的域发送给攻击者。即使您设置正确的 content-type header 以将 HTTP 响应识别为 XML、some browsers (IE) will try to sniff the content 并向用户呈现浏览器认为的内容类型（HTML 在这种情况下）。为避免这种情况，请确保在响应中设置以下 header：
X-Content-Type-Options: nosniff
因此，在响应中将此 header 与内容类型 text/xml 结合使用应该可以降低 XSS 的风险。我还建议设置 Content-Disposition header，这样文件将被下载而不是显示：
Content-Disposition: attachment; filename="bar.xml"
为了首先阻止其他站点向您的 CGI 服务发出请求，您可以使用 CSRF prevention 方法。推荐的方法是“Synchronizer Token Pattern”，这涉及创建一个绑定到用户 session 的服务器端令牌，该令牌必须与 POST 请求一起提交。使用基本身份验证的系统是否可以做到这一点由您决定。可以使用 Referer header，尽管这不太安全：
checking the referer is considered to be a weaker form of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check and some organizations or browser tools remove referrer headers as a form of data protection. There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.
In short, referer checking is a reasonable form of CSRF intrusion detection and prevention even though it is not a complete protection. Referer checking can detect some attacks but not stop all attacks. For example, if you HTTP referrer is from a different domain and you are expecting requests from your domain only, you can safely block that request.
您还应该对此进行测试以确保 script will not be executed when an XML is downloaded using Internet Explorer.