Continuing the discussion from What is MDG's position on Sikka?:
@muaddib I respectfully disagree. What I’m talking about are
slow loris type attacks over websockets that typical network firewalls have no way of identifiying if they do not do deep packet analysis (which is either hard or illegeal for ssl terminated connections anyway)
ddp specific attacks that are 100% platform specific therefore requiring the security layer to have a deep knowledge of how the platform (meteor) works and of course also keep updated as meteor gets new updates related to ddp. This would also be highly inefficient and lagging behind actual meteor versions.
So basically, you are suggesting that someone should create a C/C++ layer above DDP, that is outside the app, knows all about DDP message contents (also a legal concern by the way) and keeps updated whenever meteor gets new updates. All the while, supporting different front end servers like nginx, haproxy, apache, etc, and creating a vendor lock-in since you just cannot use meteor-only clustering options either.
But yes, of course anyone can do anything anywhere. But that is just extremely inefficient and a very odd place to do it.
Regarding our comments on owasp guidelines, well of course security is not an exact, deifinitive and static science. It keeps changing, evolving and adapting. That’s why meteor has a very talented and respected security expert on board. That being said, in the current state of affairs, meteor is known to be not susceptible to those conditions outlined on that article. (Again, except for those that the app dev can screw up)
But I am very very very interested in actual physical pointers that you might bring up. That’s why I carried over our converstion here. So that we don’t hijack the thread over there and continue freely, if you also would like to do that with me.