我最近从一个安全审计中听说HTTP选项总体上是不安全的，Web服务器不应该允许它。有人能解释一下为什么会这样吗？
cpjpxq1n1#
HTTP选项动词可以泄露Web服务器上的配置/调试数据，因此只有在合法需要时才允许。阅读此安全堆栈交换帖子https://security.stackexchange.com/questions/21413/how-to-exploit-http-methodsREST API利用了Options，我认为它应该保持启用状态。
kb5ga3dv2#
REST服务器有一个有趣的地方，它们可能会告诉你哪些方法是允许的。例如，它可能会生成这样的响应：
405 HTTP/1.1 Server: FooBar v0.1 Allow: POST,GET,DELETE,OPTIONS
OPTIONS命令返回类似的信息，它还告诉您是否支持某些标头。
OPTIONS
OPTIONS * HTTP/1.1 Host: api.example.com Access-Control-Request-Method: POST Access-Control-Request-Headers: X-PINGOTHER, Content-Type
而在你得到的答案中：
Access-Control-Allow-Methods: POST,GET,DELETE,OPTIONS Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
因此，我们看到的信息与上面的405错误相同。它支持所有CORS功能，因此它可以包括Origin，并回复它接受（或不接受）所述原点：
Origin
Origin: https://api.example.com
将得到答复：
Access-Control-Allow-Origin: https://api.example.com
有些服务器会直接在服务器的文件系统上执行PUT和DELETE命令，而OPTIONS命令的可用性会告诉你这两种方法都是受支持的。我个人不明白为什么OPTIONS会有这样的坏表现，因为尝试PUT命令也会告诉你它是否受支持。所以不管有没有OPTIONS，如果你有一个愚蠢的服务器实现，黑客都可以接管你的服务器。就我个人而言，我从来没有见过一个服务器支持PUT和DELETE直接更新您的服务器的文件！现在，如果您没有REST或WebDav或需要CORS，我会关闭OPTIONS功能，因为它真的没有用。
PUT
DELETE
cbeh67ev3#
为什么这被认为是坏的：在过去，主要问题是OPTIONS会暴露其他通过Web服务器可用的潜在危险操作。在现实中，无论OPTIONS是否告诉你，这些操作都会暴露，所以实际的危险更倾向于懒惰的攻击者容易的分析。自动化的恶意软件包通常会用已知的DELETE或PUT等命令来打开大门，而不管OPTIONS是否工作。在现代系统中：OPTIONS实际上有一个更有效的目的，关于CORS（跨站点来源）的请求通过XHR（通常JavaScript等用于现代UI的，不需要整页的表单职位等）CORS的部分要求基本上是说
"I have a request coming from this site/subdomain. What can I do"
这是通过带有Origin头的OPTIONS请求完成的，响应将指示
"OK, based on where you're coming from, you send POST and GET requests with [these headers]"
这一点很重要，因为现在很多网站使用不同的子域来实现共同的功能（包括登录等）。如果没有CORS，子域B就无法访问与通过子域A登录相关的cookie。如果浏览器不能向子域A发送OPTIONS请求，那么它将简单地放弃POST数据。没有OPTIONS，没有XHR CORS请求，这些东西很可能会崩溃。
c0vxltue4#
OPTIONS是一个诊断方法，它返回一个主要用于调试等的消息。令人惊讶的是，这个消息基本上报告了哪些HTTP方法在Web服务器上是活动的。实际上，现在很少有人出于合法目的使用它，但它确实给了潜在攻击者一点帮助：它可以被认为是找到另一个漏洞的捷径。现在，这本身并不是一个真正的漏洞;但是由于它没有真实的用途，它只会影响你的攻击面，理想情况下应该禁用它。注意：尽管如此，OPTIONS方法现在仍有几个合法用途，例如一些REST API需要OPTIONS请求，CORS需要飞行前请求，等等。因此，肯定存在应该启用OPTIONS的情况，但默认情况下仍然应该是“禁用，除非需要”。来源：https://security.stackexchange.com/questions/21413/how-to-exploit-http-methods
4条答案
按热度按时间cpjpxq1n1#
HTTP选项动词可以泄露Web服务器上的配置/调试数据，因此只有在合法需要时才允许。阅读此安全堆栈交换帖子
https://security.stackexchange.com/questions/21413/how-to-exploit-http-methods
REST API利用了Options，我认为它应该保持启用状态。
kb5ga3dv2#
REST服务器有一个有趣的地方，它们可能会告诉你哪些方法是允许的。例如，它可能会生成这样的响应：
OPTIONS命令返回类似的信息，它还告诉您是否支持某些标头。而在你得到的答案中：
因此，我们看到的信息与上面的405错误相同。
它支持所有CORS功能，因此它可以包括
Origin，并回复它接受（或不接受）所述原点：将得到答复：
有些服务器会直接在服务器的文件系统上执行
PUT和DELETE命令，而OPTIONS命令的可用性会告诉你这两种方法都是受支持的。我个人不明白为什么OPTIONS会有这样的坏表现，因为尝试PUT命令也会告诉你它是否受支持。所以不管有没有OPTIONS，如果你有一个愚蠢的服务器实现，黑客都可以接管你的服务器。就我个人而言，我从来没有见过一个服务器支持
PUT和DELETE直接更新您的服务器的文件！现在，如果您没有REST或WebDav或需要CORS，我会关闭OPTIONS功能，因为它真的没有用。cbeh67ev3#
为什么这被认为是坏的：
在过去，主要问题是OPTIONS会暴露其他通过Web服务器可用的潜在危险操作。在现实中，无论OPTIONS是否告诉你，这些操作都会暴露，所以实际的危险更倾向于懒惰的攻击者容易的分析。自动化的恶意软件包通常会用已知的DELETE或PUT等命令来打开大门，而不管OPTIONS是否工作。
在现代系统中：
OPTIONS实际上有一个更有效的目的，关于CORS（跨站点来源）的请求通过XHR（通常JavaScript等用于现代UI的，不需要整页的表单职位等）
CORS的部分要求基本上是说
这是通过带有Origin头的OPTIONS请求完成的，响应将指示
这一点很重要，因为现在很多网站使用不同的子域来实现共同的功能（包括登录等）。如果没有CORS，子域B就无法访问与通过子域A登录相关的cookie。
如果浏览器不能向子域A发送OPTIONS请求，那么它将简单地放弃POST数据。没有OPTIONS，没有XHR CORS请求，这些东西很可能会崩溃。
c0vxltue4#
OPTIONS是一个诊断方法，它返回一个主要用于调试等的消息。令人惊讶的是，这个消息基本上报告了哪些HTTP方法在Web服务器上是活动的。实际上，现在很少有人出于合法目的使用它，但它确实给了潜在攻击者一点帮助：它可以被认为是找到另一个漏洞的捷径。现在，这本身并不是一个真正的漏洞;但是由于它没有真实的用途，它只会影响你的攻击面，理想情况下应该禁用它。注意：尽管如此，OPTIONS方法现在仍有几个合法用途，例如一些REST API需要OPTIONS请求，CORS需要飞行前请求，等等。因此，肯定存在应该启用OPTIONS的情况，但默认情况下仍然应该是“禁用，除非需要”。
来源：https://security.stackexchange.com/questions/21413/how-to-exploit-http-methods