Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10

Subject: Re: [boost] [review][beast] Review of Beast starts today : July 1 - July 10
From: Nik Bougalis (nikb_at_[hidden])
Date: 2017-07-07 13:51:45

On Thu, Jul 6, 2017 at 1:32 PM, Artyom Beilis via Boost
<boost_at_[hidden]> wrote:
>
> > May be there could be more hints for client/server developers.
> > E.g. where is the best place / how is the best practice to add
> > cookie-handling, Authentication challenges, etc.
> >
> >
>
> Funnily, for someone who actually solved numerous of the issues this
> question can easily be rephrased as:
>
> > Now I finally learned how drive a bicycle,  lets ask tips for driving semi-trailer.
>
> And this is **the major** problem of the library.
>
> In the CppCMS frameworks the HTTP part is less than 2.5% of the core
> code. The rest is the "minor" stuff like cookies, session, url parsing
> and much-much more. And note - I'm talking about server part only

There's no denying that "raw" HTTP is _almost_ simple before all
these other "minor" things that a full-fledged server or client needs are
thrown in.

But I think it's important to look at the goal of the library, per the author:
to enable others to write rich client and server libraries on top while it
takes care of the bottom-most plumbing in the most efficient way.

I think it achieves that. Hands down.

> Now once you choose to use Beast you'll hit the wall very quickly as
> you'll have to do all tricks your own and they will consume most of
> your work for example URL decoding, parsing query string, parsing or
> generating trivial forms or handling trivial cookies. So instead of
> concentrating on your application issues you are going to deal with
> 1001 small issues that require both experience and knowledge to do
> them right.
>
> The biggest problem is actually that vast majority security issues do
> not come from HTTP parsing at all, but rather all "minor stuff" [1]
> that left out of scope of the Beast.
>
> This question you had written had popped for me the big red flag -
> without proper well organized tools that handle the "minor stuff"
> Beast users are virtually doomed to writing insecure code. Unlike most
> HTTP servers/clients are build with security by design - do safe stuff
> by default, Beast lives this ALL to end user.
>
> This part **extremely** concerns me - as somebody who actually
> developed both web services and tools to make them secure and aware of
> unforgiving nature of WWW.

I appreciate you raising this, Artyom. Beast should be held to a high
standard, especially since it's handling user-input from untrusted
channels (i.e. socket buffers). So yeah, the code should be written
carefully, without thorough error checks, especially around the
handling of memory.

Based on my informal audit of the codebase, and my interactions with
Vinnie, I know that it is written carefully and am very confident that it
does not contain any bugs that would compromise the security of an
application built using it.

With that said, I also think you're exaggerating just a little bit. I just
don't think you need to be _THAT_ worried.

Yes, adding full "client" or "server" support, with cookie jars, and
authentication methods and tracking of origins, and who knows
what else, is not for the faint of heart.

Yes, some will try to implement such things themselves and they
will mess it up. Spectacularly. But is that different than _any_
other library? Can't people spectacularly mess up multithreaded
programming? Should we have held that against Boost.Thread?

Yes, if you want a full-fledged client or server library, there are
better alternatives than Beast. As Vinnie has said, Beast will
never be curl, or CppCMS and  it doesn't need to!

The idea is to offer a robust implementation of the lowest HTTP
plumbing to (a) enable robust and clean WebSocket support
and (b) allow others to more quickly and easily write such
full-fledged client or server libraries layered on top of Beast
that are efficient without needing to worry about the bottom
layer of HTTP plumbling.