This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] HTTP/HTTPS probe
- Previous message (by thread): [atlas] HTTP/HTTPS probe
- Next message (by thread): [atlas] HTTP/HTTPS probe
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Richard Barnes
rlb at ipv.sx
Thu Nov 21 15:18:22 CET 2013
On Thursday, November 21, 2013, David Precious wrote: > On Wed, 2 Oct 2013 14:13:11 -0400 > Richard Barnes <rlb at ipv.sx> wrote: > > > (3) is a huge security risk, because of the wide variety of things > > that are done with HTTP requests. For simplicity, let's assume the > > probe would send a GET request, and not anything more sophisticated > > (POST, PUT, DELETE, etc.). You could use a GET request to download a > > file, but you can also a GET request to do things to supply responses > > to HTTP forms. Want to make sure your favorite band wins the > > EuroVision Song Contest? Just task the Atlas network have 1000 > > probes vote for them every 5 minutes. > > GET requests should not alter state; if they do, arguably the problem > there lies with the design of the faulty website. > > Indeed, that is what the HTTP spec says. But there are a good number of fault websites out there, and it seems bad to have Atlas be a tool to exploit them. In theory, there's no difference between theory and practice, but in practice there is :) -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/ripe-atlas/attachments/20131121/d752514e/attachment.html>
- Previous message (by thread): [atlas] HTTP/HTTPS probe
- Next message (by thread): [atlas] HTTP/HTTPS probe
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]