Some of the libraries do have APIs to let the user specify maximum size-limits (for instance I think the Java protocol implementations support this).
Most of it is not rocket science, it's just a matter of going in and making sure the library objects all have the appropriate APIs to let the user specify what the size limits should be. This work is not complete across all the language library implementations. In C++ there is a more complex vulnerability, which is that stack overflow can be created by a rogue client sending an infinitely-nested sturct-of-struct-of-struct..., which would cause TProtocol::skip() to keep allocating stack frames. -----Original Message----- From: Mayan Moudgill [mailto:ma...@bestweb.net] Sent: Monday, April 26, 2010 1:52 PM To: thrift-dev@incubator.apache.org; Mark Slee Subject: Re: Anyone using Thrift for public endpoints? I was wondering - isn't part of the problem that there is no way for a user to handle these issues, that they are handled in the Thrift library layer, so to speak? Suppose a user wanted to add the behavior: "abort if an RPC message is going to allocate more than 1MB data". Can a user do this? Or will he have to hack the library code? Mark Slee wrote: > Wrapping Thrift up in protocols like HTTP can help alleviate some of the > common > issues and is a pretty reasonable thing to do. > > But make no mistake, you still need to protect against the real issues. Even > if > you use HTTP, someone can still send a bogus request that *claims* to contain > a > 1GB string and trick the server into a huge allocation, even if the HTTP POST > request is < 1K in size. > > Same goes for arguments about framing, etc. Even with a framed transport, > nothing stops someone form intentionally sending a bogus frame size. > You do need to make sure that your Thrift code is equipped to handle all these cases. > -----Original Message----- > From: Aron Sogor [mailto:big...@gmail.com] > Sent: Sunday, April 25, 2010 5:50 PM > To: thrift-dev@incubator.apache.org > Subject: Re: Anyone using Thrift for public endpoints? > > It depends.. If you talking about raw socket protocol, sure you need some > flow control and there is no such thing out of box. > > If run over HTTP that your HTTP container probably can limit the POST > size... so you probably will not crash the server. > > Aron > > On Thu, Apr 22, 2010 at 1:24 AM, Mathias Herberts < > mathias.herbe...@gmail.com> wrote: > > >>Given that Thrift still suffers from crashes due to invalid data being >>entered, I would not yet consider this a safe practice. >> >>Maybe after GSoC. >> >>But facebook does it for a test service IIRC. >> > > >
