GraphQL and Bot protection

[Jim Weiler]

SInce GraphQL APIs are often internet exposed endpoints, they will be the target of Bot attacks. Even if the resolvers provide authentication and authorization the GraphQL URl will be probed and subjected to high volume requests from Bots..

Because many Bot control services architectures rely on a list of API endpoints to know which APIs to protect, that architecture won't work with GraphQL because all GraphQL requests go to the same endpoint. 

Our only solution which does not require the GraphQL request creator to add a HTTP request header which would indicate that the request should be protected, is to send ALL GraphQL requests to the Bot control service. We are trying to keep the GraphQL flexibility that lets the requester change their query whenever and however they want, without consulting some list of sensitive fields, which, if any of those fields occur in a query, means that the request must be marked as needing Bot protection.

Has anyone tried to provide Bot protection to GraphQL APIs? This is not WAF protection. This is protection from credential stuffing, malicious crawling / scraping, DDOS etc.

Thanks, Jim

[Sri]

This is something we are evaluating as well. We currently use Perimeter X as bot defender. This is easy to use for traditional website and rest API's and we are evaluating how this can be used for GraphQL. Perhaps we can build something which parses query and send them to PerimeterX but will be overhead to maintain. 

I am also curious what bot defenders other teams are using for GraphQL 

[Adam Fisher]

In my experience, the major issue with the WAF and traditional BOT players is that they rely on some browser telemetry to identify if you are a bot or a human accurately. Unfortunately, this doesn't work for all APIs, as they are still available publicly but are not browser web-based APIs. Thus you get False Positive galore when you add those endpoints behind a WAF.  

Jim highlights the next issue with the Traditional App Security approach, where you have to add each endpoint to know which APIs to protect. This is even more complicated, as Jim states when using GraphQL. This became a puzzle of complex rules and policies because I had to add the rate-limit rule on each endpoint path, not the actual domain. Granted, our YMMV, but this was my experience when I worked at a leading WAF vendor and why I work for a dedicated API security vendor that alleviates these issues today.  

The industry is moving to APIs, but the methods to protect them still need to catch up.

Kind regards, Adam

Adam Fisher Principal Security Engineer CISSP, CCSP, AWS Solutions Architect MCA - Azure Ad...@salt.security / +1 (801) 616 9031 https://salt.security  https://calendly.com/adam-saltsecurity

--
You received this message because you are subscribed to the Google Groups "API Security Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-security-pro...@owasp.org.
To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/d2b4079a-e233-4b81-a0b9-a8c4e589e886n%40owasp.org.

[Owen Rubel]

well the issue with GraphQL is that it is a DIRECT binding to domain/model with 'modest' automated controller (at best) and limited security.

API's have controller/filter/interceptor and many layers to add security/checks in place.

I think rate limiting is the only thing stopping most all out brute force attacks but it would not stop a bot-net juggling the attack

Owen Rubel
oru...@gmail.com

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/CADZTyAecf1rYHjx4mB%3DnVUkckSnbKREDHVQekVCmkiDt1MrgzA%40mail.gmail.com.

[Owen Rubel]

The easiest way to grab the hash is to spoof an address between you and a proxy/vendor so as to intercept a hash.

Most people do not associate the IP with the hash so this is quite simple.

Once this is done, you have full access to that client/ROLE

Owen Rubel
oru...@gmail.com

On Wed, Jan 5, 2022 at 9:02 AM 'Adam Fisher' via API Security Project <api-securi...@owasp.org> wrote:

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/CADZTyAecf1rYHjx4mB%3DnVUkckSnbKREDHVQekVCmkiDt1MrgzA%40mail.gmail.com.

[Adam Fisher]

" I think rate limiting is the only thing stopping most all out brute force attacks but it would not stop a bot-net juggling the attack"

So true, Brute Force is beginning to be thing of the past.  Most credential stuffing attacks I deal with now max 2 requests from the same IP in 24 hours.  Hardly a brute force but attacks nonetheless.  You have to start looking at API Sequencing and baselining normal user behavior.  Basically looking at every aspect of your APIs and not just a single attack type to spot the nastiness.

Kind regards, Adam

Adam Fisher Principal Security Engineer CISSP, CCSP, AWS Solutions Architect MCA - Azure Ad...@salt.security / +1 (801) 616 9031 https://salt.security  https://calendly.com/adam-saltsecurity

[Sri]

I know SALT does this API Sequencing and baselining normal user behavior.

I am curious when SALT mirrors API traffic how can SALT prevent active attack ?  Like Perimeter X blocks API and responds with blocked error code is there any similar functionality from SALT ? 

[Dan Barahona]

This is one of the fundamental challenges with monitoring-based security approaches. If they're not inline then they can't block traffic, and can only alert to suspicious activity. The other challenge is hackers will do their best to fly under the radar - so baselining "normal" behavior can be tricky. Build a tight baseline and you get false positives. Build a loose one and you get false negatives. This isn't to say monitoring API traffic isn't effective - it's valuable. But it's equally important, though, to really pressure-test APIs pre-production to make sure they are free of security vulnerabilities and logic flaws.

Dan

<disclosure>I work for APIsec.ai</disclosure>

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/9ac84442-0783-4d7d-8cdf-4cbe6e02a312n%40owasp.org.

[Owen Rubel]

Actually not a challenge. You just have to have a shareable state file and not bind data to function:

https://gist.github.com/orubel/159e94db62023c78a07ebe6d86633763

Owen Rubel
oru...@gmail.com

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/CAJ55VTPqkXCQ3cNgU90JXZoaznBpy-xNS6zJJhSuiFNrimXvAw%40mail.gmail.com.

[Giora Engel]

Hi Sri,

I represent Neosec, a Salt competitor, but believe my answer here is not product specific.

True analytics (sequencing, profiling, behavioral analytics) requires non-in-line implementation, because you need to take into account the last 30 days of behavior when assessing new behavior.

Once detected you can implement certain automated response functions, directly from the product, such as blocking the user traffic via the API Gateway or WAF. I will share some learning on what makes it possible to implement automated response safely and effectively:

• The granularity of the response needs to be accurate - for example it is typically not enough to block the IP, but instead you need to block the offending user-ID or API Key. Blocking an IP is not accurate and can risk good traffic. 
  
• It helps to implement a timeout, so that the blocking or or rate limiting will apply for a limited amount of time until the case is further investigated.
• It is important to have a way to query and threat hunt to see what happened in order to design automated flows. Threat hunting enables us to go back into the data and ask questions like "does this happen frequently", "how many users exhibit that behavior or use case". Without access to the data it is hard to design a blocking action blindly.

On Wed, Jan 5, 2022 at 1:24 PM Sri <srivalli...@move.com> wrote:

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/9ac84442-0783-4d7d-8cdf-4cbe6e02a312n%40owasp.org.

[Owen Rubel]

"The granularity of the response needs to be accurate - for example it is typically not enough to block the IP, but instead you need to block the offending user-ID or API Key. Blocking an IP is not accurate and can risk good traffic."

This is WHY you associate the TOKEN with the IP on the backend. By blocking the IP associated with the TOKEN, you do all the above.

Owen Rubel
oru...@gmail.com

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/CAH_eSXYz%3D2n_rnSk6H7BY8hdiXwtZrzkdGwudpCC2rHtqsibUw%40mail.gmail.com.

[Jim Weiler]

Hi Owen,
I couldn't understand your comment of Jan 5, 2022, 7:58:48 PM, or the code snippets at the Gist link. Regarding your Jan 8 comment, what token? If you mean the authentication token to call the API,  for mobile apps you have to assume the token is public or discoverable by anyone, so all bots and real app instances on user devices will use that token, the token won't help block just bots.

To everyone,
Our initial testing of our bot service to discriminate between GQL requests from an emulator running the mobile app (these requests would look like a bot) and devices running the mobile app (these requests are legitimate) was successful.  Only a small subset of GQL operations are protected. The routing of just the protected requests to our bot service by our CDN (which is inline for all API requests) is accomplished by using Apollo (Enterprise version) Safe Lists, where a hash of each query is registered on the server and each hash is configured on the server to call a resolver. The calling code always has to send the hash value of the desired operation in the request header and the CDN has a table of hashes of protected queries to route to the bot service.
A critical feature of the bot service is to be able to determine that a legitimate burst of API calls from an app instance running on a device, is not a replay attack by a bot. Some single user actions in the app, generate a sequence of the same API calls, which are obviously sent inhumanly fast, and that burst could look like a replay attack from a bot. 
Jim

To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.

To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/api-security-project/9ac84442-0783-4d7d-8cdf-4cbe6e02a312n%40owasp.org.

--
You received this message because you are subscribed to the Google Groups "API Security Project" group.

To unsubscribe from this group and stop receiving emails from it, send an email to api-security-project+unsub...@owasp.org.