🚀 Feature: Web Security Scanners

[stnguyen90]

🔖 Feature description

Since you are already running an Antivirus, here is another suggestion: Web security scanners. Like skipfish. Like the w3af. Like dictionary / word list attacks. Like Nexpose of Rapid7. Those could be scheduled or manually run web application security audits.

🎤 Pitch

this is the least pressing idea, since we assume the Appwrite code to be well audited after review, and consideration of the salted hashing algorithm, but noonetheless, the API key privileges and DB docs protection might yield a lot of unwanted leaks, that are automatically detectable by these scanners.

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Originally posted by @zdanl in #5053

[stnguyen90]

@zdanl, it makes sense to build file scanning into Appwrite because there is logic in Appwrite to scan files right when they're uploaded. From my experience, web security scanners are typically separate from the application itself and it would probably be best to decouple them.

[eldadfux]

@stnguyen90, @abnegate has been doing some research on this area. @abnegate it might be a good idea to add the following suggestions to your lists.

[zdanl]

I'm nowhere near fully understanding the security model exposed to the user as to API keys and AppWrite's own security standing as to dealing with fraudulent input, thus, my suggestions are limited to - but I would like to firmly reiterate on that - I was suggesting externally scanning the web application run with Appwrite with advanced tools such as:

• https://github.com/spinkham/skipfish, this was written by a most prominent member of infosec, lcamtuf formerly Security Manager of Google, and is a C implementation of smartness not fully supporting Javascript to the best of my knowledge. But it is fast and generates a readable report
• http:https://w3af.org/, this is a framework by Andres Riancho and many others, which includes full exploit capabilities and a lot of scenarios. It is not very good on reporting
• https://www.rapid7.com/products/nexpose/, I was involved in the development of this as to dialogue with Dan Kuykendall when presenting by own Javascript capable scanner at DEFCON 20, at a stage, when including fully fledged web browsers was a novelty in security, therefore, it does support Javascript, can infringe on business logics, and be barely invisible in its capability as a web vulnerability scanner.

If there is anything we can do to sharpen the permissions of API keys with a wizard rather than granularity settings, which in my understanding, per default, allow to broadly operate in the context of the Backend, that would be very good. Pointing out the understanding of Javascript from a security perspective, as opposed to for example Nessus, as a key feature, given the SDK and the valueable semantics of AppWrite calls exposed in the Frontend ready for Parsing. If parsing in this case is too abstract, I would infer OpenAI ChatGPT for example, which can make assumptions on AppWrite SDK statements in the browsers, and neatly fully comprehend the implementation of those API calls if provided with the source code.

This may be going to far, but whereelse to leave such thoughts if not in this ticket.

[iamabhiCH]

Hi @stnguyen90 I just explored this and I found it amazing. Would you please assign this issue to me?