Hi Frank,
> OK - an attacker is characterized by being an anonymus.
I would say NO ... instead, a attacker is characterized by accessing/using
an "unknown API". He wanders into the honeypot.
> What if somebody registers regularly, then turns into an attacker?
No alowed user/token will use this
OK - an attacker is characterized by being an anonymus. What if somebody
registers regularly, then turns into an attacker? This happens quite
often, e.g. if an employee is fired or feels treated badly, and he wants to
damage his employer. Then, the attacker is not anonymus - we might be able
to
Sure, you get information *about* the attacker from such headers. But how
do we *detect* (!) an attack - also from headers? Or do you have a
catalogue of IP addresses that are allowed to use the API (then, detection
would be simple)...
Best regards,
Frank
Am Fr., 10. Mai 2019 um 07:37 Uhr
In deed: very nice idea, valuable feature! Which attributes should be used
to detect an attack?
Best regards,
Frank
Am Do., 9. Mai 2019 um 11:09 Uhr schrieb Sanjeewa Malalgoda <
sanje...@wso2.com>:
> Tracing and logging problematic API calls definitely add value to product.
> This is kind
On Thu, May 9, 2019 at 2:39 PM Sanjeewa Malalgoda wrote:
> Tracing and logging problematic API calls definitely add value to product.
> This is kind of alerting mechanism. But we should not stop from there. We
> can go one step ahead and block calls with similar attributes. We can block
> API
Tracing and logging problematic API calls definitely add value to product.
This is kind of alerting mechanism. But we should not stop from there. We
can go one step ahead and block calls with similar attributes. We can block
API calls temporary based on the API context, application id, user and IP
