Parse Security (by obscurity)

Big fan or Parse, built a lot of stuff with it. Ideal for prototyping and we all are aware of the pitfalls of using this framework for a project which goes from prototype to prod overnight. ACL, CLP etc.

I wont bore anyone with things which are posted over and over but… it would be nice to at least have some security by obscurity, i.e it is blatantly obvious to anyone who is looking for a vuln that parse is running the show

Can we somehow allow that any Parse named code can be renamed, any headers the same, server responses that don’t throw back the full ACL objects by default, I think before we lock down documents/objects by ACL this would at least offer some defence by obscurity.

A good thought, that sounds difficult to achieve. There will likely always be some characteristic that will give away that Parse Server is listing on the other end. For example the semantics of a response to a certain request or a common endpoint like /health. And if a single characteristic is ambiguous, then a combination of 2 or more characteristics will likely give it away.

A giveaway can also be the client SDK. There are services that automatically analyze apps on app stores, debug them and list all their SDKs. So one could look for a recently published vulnerability (whatever the backend technology), then look for an app that uses the related client SDK, then target that service.

Do you have a list of Parse Platform characteristics that you would want to be customizable for obscurity?

Yeah the clientSDK is for sure a give away, and i guess if they stumble on the client facing site first and its using parse its pretty obvious the backend is parse too, although maybe just one thing would be to be able to use custom headers that are not identifying the parse server, for instance i was able to find a number of parse backends running via shodan some of which it would be possible to view the some entire collections (of course i didnt) had the parse headers not been exposed i would never have been able to do this.

I guess it would be a simple feature to add to set custom header names. A developer would need to set the same custom names for the server and each of the SDKs. Shouldn’t be too difficult to implement as these header names are likely defined only once as constants.

I think in the SDK you guys already have something, although last time i tested it Im not sure i was seeing my header getting passed so maybe im wrong (or maybe i need to check again)

 Parse.CoreManager.set('CUSTOMHEADER', "SOMEVALUE")

so in that case its just a tweak to the server to allow the custom headers and map them to the parse ones (likely from server config)

This feature is for adding custom headers in addition to the internal parse headers like X-Parse-Application-Id if I’m not mistaken. So what you’re looking for is a new feature.

Besides, these headers should not be publicly visible in a TLS connection. So if your website appears on shodan with these headers then the issue is likely an insecure connection. A MITM attack could of course expose these headers, but then even login passwords and session tokens would be exposed, so that’s a different scope. And even in that scope, the solution would likely not be changing the header names but to use DNSSEC.

Its possible, It was something i did a couple of months ago so im guessing especially as it was on shodan that i was finding people who not only misconfigured their servers allowing access at port 80 on the default nginx config which allowed their headers to be exposed alongside misconfigured parse instances.