search

OWASP / SecurityShepherd

Web and mobile application security training platform
https://owasp.org/www-project-security-shepherd/
GNU General Public License v3.0
1.35k stars 460 forks source link

Improve bad submission handling #532

Open etnoy opened 4 years ago

etnoy commented 4 years ago

As of now, Shepherd removes points when users do bad submissions.

We've had issues where students use ZAP and inadvertently use an attack tool such as a directory traversal scanner. This sends several hundred requests to the result key submitter and then removes all their points.

The core issue is that the countermeasures are ineffective. Just removing points and writing a warning in the returned HTML output is not very good if the other end is ZAP and not a user using a browser.

I suggest that bad submissions first should result in the user being logged out. If attacks continue, the user should be banned for a minute, then 10 minutes, then an hour. This makes sure that unwitting users (who often are complete beginners to infosec and attack tools) don't do things they don't want.

venkatdvs111 commented 3 years ago

As of now, Shepherd removes points when users do bad submissions.

We've had issues where students use ZAP and inadvertently use an attack tool such as a directory traversal scanner. This sends several hundred requests to the result key submitter and then removes all their points.

The core issue is that the countermeasures are ineffective. Just removing points and writing a warning in the returned HTML output is not very good if the other end is ZAP and not a user using a browser.

I suggest that bad submissions first should result in the user being logged out. If attacks continue, the user should be banned for a minute, then 10 minutes, then an hour. This makes sure that unwitting users (who often are complete beginners to infosec and attack tools) don't do things they don't want. Duplicate of #

rudosch commented 1 year ago

I don't think it's a good idea to logout a user upon the first few bad submission. But this could be done later on if the student would no longer receive points. Students that inadvertently send automated requests should learn that this is not the way to use SecurityShepherd (maybe there should be a message about this on startup). If needed, it is possible to add the points manually for the student, after the student has contacted the admin.

etnoy commented 1 year ago

Please reread the description. Students don't really intend to do the automatic attacks but inadvertently click the button which has very bad consequences that can't be undone even by an admin.

rudosch commented 1 year ago

Please reread my comment. I'm not saying that you can completely prevent these automated attacks, that's not my point. My constructive suggestion would be not to logout the student on the first bad submission, but only on the second or third attempt within a few seconds. I suggest to record a timestamp of the last bad submission and check it on the next one. Then this student could be logged out and/or suspended.