[Solaris]

Ursprungligen postat av MMC

Bra med ett demokonto, har tittat runt lite i det nu.

Lite förbättringsförslag:
* Varför måste jag "choose a website" för varenda funktion jag tittar på? Jag tror att det vore bättre att man kunde välja att jobba med en sajt på ett ställe, ungefär som Google Analytics gör. Ännu bättre vore så klart att inte fråga vilken sajt man ska jobba med förrän man lagt till två eller fler.

* Jag saknar förklaringar på vad "Einards status" innebär. Det är massor med röda kryss där på demokontot men det förklaras inte vad det betyder eller vad jag kan göra åt det.

* Försök vara konsekvent med namn på typer av attacker osv. Om ena typen heter XSS så kanske det räcker att kalla SQL-injektioner för SQL och inte "SQL-injections" (ska inte vara ett bindestreck där btw) eftersom det då ser märkligt ut i listan över attacker.

--

Men jag måste bara fråga en sak nu. Du sparar alltså bara URL:en för varje sidvisning, och får därmed GET-variabler som du troligtvis kör genom ett antal regexar för att upptäcka "misstänkt" input. Vad händer med POST-variabler? Jag kan ju lika gärna göra ett SQL-injektionsförsök genom ett POSTat formulär. Om din tjänst inte stödjer det så vore det kanske bra att förtydliga detta.

Ett tips på funktion som kan vara bra för att upptäcka och förhindra XSS: spara Referer-strängen för alla anrop och skriv lite kod som upptäcker när t.ex. ett formulär POSTas med en Referer som skiljer sig från vad det brukar vara för det formuläret.

Slutligen vill jag bara poängtera att jag tycker att det är skitkul att se ett sådant här ambitiöst projekt från någon så ung, så se mina synpunkter som konstruktiv kritik och tappa inte sugen. Du kommer att lära dig sjukt mycket genom att arbeta med detta även om du kanske inte tar över världen med just denna tjänst.

Ska besvara varje punkt nu.

Choose a website är ren lathet från min sida, detta kan absolut finslipas.
Förklaringar för Einards status känns väl ibland lite överflöda, men vissa saker kan vara oklara. Såsom E.S.P, Filter, Encryption m.fl. Ska lägga till det på "to do list".
Kan också ta bort bindestrecket på texten "SQL-injection" bland graferna.

Det är alldeles korrekt att jag tar URLen och kör genom ett antal regexar, har dock även en del andra äss i rockärmen för att förfina metoderna att urskilja skadliga URLer från "ok" URLer. Exakt vad det är vill jag inte gå in på.

Men, angående POST. I alphan utav Einards så fanns det faktiskt en funktion där man kunde kontrollera sin POST-data, så den funktionen fanns/finns på det gamla systemet.

Felet låg dock i följande:

1.) Folk känner sig lite nojiga ifall dom skickar ut känsliga värden från deras forms till einards, d.v.s folk kanske inte vill skicka ut lösenord, kunduppgifter etc till oss.
Sen det största problemet var att kontrollera POST-datan, tänk dig bara denna forumspost. Ifall allt detta skulle kontrolleras så blir det massiva strängar att skicka som parametrar till Einards, detta klarade inte Einards av och det blev en jävla massa errors hit och dit.

Går ju dock att lösa på vissa sätt, exempelvis en funktion där man kan kontrollera input-forms som har en maxlimit mindre än 50 tecken eller dylikt. Fast som sagt, privacyn är också lite nojig.

Tack för tipset angående referersträngen! Riktigt bra idé, ska försöka implementera detta.

Och slutligen, tack för den underbara feedbacken. Och det du skrev värmer verkligen i mitt hjärta.