Muss ich auf allen meinen Seiten `[ValidateAntiForgeryToken] und @ Html.AntiForgeryToken()` verwenden?

Question

All Seite meines Projektes benötigt Authentifizierung .. Und ich nicht Normalerweise [ValidateAntiForgeryToken] and @Html.AntiForgeryToken() auf meinem Controller verwenden und anzeigen .. Nur Login-Seite hat es ..

1. Was sind sie [ValidateAntiForgeryToken] and @Html.AntiForgeryToken() ??
2. Muss ich sie verwenden ??
3. Welche cookieless muss ich verwenden ??

Mein web.config Teil wie folgt;

<authorization> 
    <deny users="?" /> 
</authorization> 
<authentication mode="Forms"> 
    <forms loginUrl="~/User/Login" timeout="30" cookieless="UseDeviceProfile" name="AbosSMSP" /> 
</authentication> 

Mein Fehler wie diese;

Answer 1

Denken Sie an das Anti-Forgertoken ist ein Weg, um sicherzustellen, dass die Anfrage, die zu einer Post-Aktion kommt, tatsächlich eine ist, die aus Ihrer ausgegebenen Ansicht stammt. Es stoppt Cross-Site-Scripting-Angriffe und ich denke, es behandelt auch Post-Replay-Angriffe.

Das Sichern der Haustür zu Ihrer Anwendung ist ein guter Anfang, es stoppt Menschen, die ihre Daten mit roher Gewalt gestohlen haben, jedoch stoppt es nicht alle Arten von Angriffen. Dinge wie Social Engineering und Phishing können jemanden auf Ihrer Seite hereinlassen, ohne dass sie die Anmeldeseite durchbrechen.

Sobald es soweit ist, gibt es alle Arten von Gemeinheiten, die sie bewältigen können. Sehen Sie sich daher die OSWAP-Empfehlungen an und prüfen Sie, ob andere Angriffe für Sie anfällig sind. Wenn Sie Zweifel haben, können Sie Ihren Site-Pen von ethischen Hackern für ein paar hundert Stirling testen lassen, wenn Sie sich um sensible Daten kümmern, dann würde ich das empfehlen, da sie Dinge aufziehen, die Sie vielleicht gar nicht haben Denk an.

Meine Top-Tipps für die Sicherheit

1. Antiforgerytoken auf der Login-Seite
2. Langsam alle Authentifizierungsversuche von mindestens einem zweiten nach unten (macht Brute-Force-unpraktisch)
3. ein Konto Umsetzung der Verfahren auf n aussperren Mengen von ungültigen Anmeldungen
4. immer eine generische Fehlermeldung auf dem fehlgeschlagenen Logins verwenden Hacker zu verhindern, zu wissen, welche
5. immer verschlüsselt falsch ist Ihr Teil eines Login Passwörter in der DB mit einem Salz, sollten das Salz pro Benutzer sein, eine Rainbow-Attacke auf einem gestohlenen Datenbank
6. Achten Sie immer darauf, dass alle Daten angezeigt oder abgerufen zu verhindern, gilt für diesen Benutzer
7. immer parametrisierte SQL verwendet
8. versuchen Sie, und verschleiern die IDs übergeben um in Ihre Urls und Ansichten Änderung oder den Versuch einer direkten Bezug Angriff

im Anschluss an das zu verhindern, ich glaube, Sie ohne Abdeckung werden die meisten von dem, was ein Pen-Test erhöhen würde, und legen Sie auf eine gute Stelle für eine sichere Seite