1. 25 8月, 2023 1 次提交
  2. 18 8月, 2023 1 次提交
  3. 11 8月, 2023 2 次提交
  4. 09 8月, 2023 1 次提交
  5. 27 7月, 2023 1 次提交
  6. 25 7月, 2023 2 次提交
  7. 20 7月, 2023 1 次提交
  8. 05 7月, 2023 1 次提交
  9. 29 6月, 2023 2 次提交
    • R
      Implement more comprehensive SSRF mitigation (#6362) · 16d03aac
      Roman Donchenko 提交于
      The current mitigation approach (resolving the IP address and checking
      if it's in the private range) is insufficient for a few reasons:
      
      * It is susceptible to DNS rebinding (an attacker-controlled DNS name
      resolving to a public IP address when queried during the check, and to a
      private IP address afterwards).
      
      * It is susceptible to redirect-based attacks (a server with a public
      address redirecting to a server with a private address).
      
      * It is only applied when downloading remote files of tasks (and is not
      easily reusable).
      
      Replace it with an approach based on smokescreen, a proxy that blocks
      connections to private IP addresses. In addition, use this proxy for
      webhooks, since they also make requests to untrusted URLs.
      
      The benefits of smokescreen are as follows:
      
      * It's not susceptible to the problems listed above.
      
      * It's configurable, so system administrators can allow certain private
      IP ranges if necessary. This configurability is exposed via the
      `SMOKESCREEN_OPTS` environment variable.
      
      * It doesn't require much code to use.
      
      The drawbacks of smokescreen are:
      
      * It's not as clear when the request fails due to smokescreen (compared
      to manual IP validation). To compensate, make the error message in
      `_download_data` more verbose.
      
      * The smokescreen project seems to be in early development (judging by
      the 0.0.x version numbers). Still, Stripe itself uses it, so it should
      be good enough. It's also not very convenient to set up (on account of
      not providing binaries), so disable it in development environments.
      
      Keep the scheme check from `_validate_url`. I don't think this check
      prevents any attacks (as requests only supports http/https to begin
      with), but it provides a friendly error message in case the user tries
      to use an unsupported scheme.
      16d03aac
    • A
      Bump version to 2.4.9 · 75c1e6ff
      Andrey Zhavoronkov 提交于
      75c1e6ff
  10. 22 6月, 2023 1 次提交
  11. 16 6月, 2023 3 次提交
  12. 12 6月, 2023 2 次提交
  13. 09 6月, 2023 1 次提交
  14. 03 6月, 2023 1 次提交
  15. 02 6月, 2023 2 次提交
  16. 18 5月, 2023 1 次提交
  17. 25 4月, 2023 1 次提交
  18. 14 4月, 2023 1 次提交
  19. 06 4月, 2023 1 次提交
  20. 16 3月, 2023 2 次提交
  21. 06 3月, 2023 1 次提交
  22. 28 2月, 2023 1 次提交
  23. 23 2月, 2023 1 次提交
  24. 07 1月, 2023 1 次提交
  25. 29 12月, 2022 1 次提交
  26. 28 12月, 2022 2 次提交
  27. 23 12月, 2022 1 次提交
  28. 16 12月, 2022 1 次提交
  29. 02 12月, 2022 1 次提交
  30. 19 11月, 2022 1 次提交
  31. 05 11月, 2022 1 次提交