Ich wurde von meinem QA-Team berichtet, dass unsere Anwendung mit SQL Injection angegriffen werden kann. Jede unserer Abfragen wird jedoch dynamisch erstellt. Wir verwenden eine API für ähnliche Abfragen wie Hibernate. Wir bereiten die Anweisungen immer vor der Ausführung der Abfragen vor und verwenden keine gespeicherten Prozeduren. Das QA-Team verwendet ZAP zum Scannen der Anwendung. Also, was muss ich tun, um ZAP SQL Injection Alerts zu vermeiden?Wie kann ich ZAP SQL Injection Alerts vermeiden, wenn meine Anwendung bereits gegen diesen Angriff gesichert ist?
Antwort
Alle automatisierten Scanner können Fehlalarme melden. Jemand muss bewerten, ob die gemeldeten Probleme falsch positive oder echte Probleme sind.
Wenn sie sind Fehlalarme dann können Sie entweder:
- Änderung der threshold for the specific rule to High
- Änderung der Schwelle auf Aus, so dass es laufen doesnt
- context alert filters erstellen, um sie automatisch Fehlalarme zu ändern
Bitte richten Sie auch ein ZAP-Problem, so dass wir sehen können, ob wir den Code beheben können, so dass falsche Positive nicht gemeldet werden.
Simon (ZAP Project Lead)
Dank @Psinon für Ihre Antwort, ich habe mit QA gesprochen und vereinbart, die SQL-Injection-Warnungen als Medium zu behandeln und die Benutzereingaben nur für den Fall zu filtern. Wir werden ein ZAP-Problem ansprechen, damit wir Ihnen helfen können, Ihr Produkt zu verbessern. –
ich nicht speziell über das Deaktivieren ZAP SQL-Injection-Benachrichtigung beantworten kann, obwohl die Dokumentation scheint darauf hinzudeuten, dass Sie so tun würde, durch diese Tests über die entsprechende Scanrichtlinie zu deaktivieren. Ich schlage jedoch vor, dass Sie Ihr QA-Team auf Einzelheiten der SQL-Injection-Sicherheitslücken drängen, die ZAP in Form von testbaren Fällen meldet, um durch * testing * und nicht durch Argumentation und Überzeugung zu verifizieren, dass Warnungen sind falsch positive. –