SQL Syntax

Alltså - du kan ha hur många funktioner som helst i include-filer, men om du inte kallar på funktionen så körs den ju inte. Exempel:

strSQL = "SELECT * FROM foo WHERE id = " & fixbug(Request.Querystring("userid"))

Jag vet inte om du måste escape:a backslash som du gjort i funktionen fixbug(), det skulle i så fall vara något som är specifikt för MySQL.

Använd funktionen fixbug() (och byt gärna namn på funktionen) på de värden som skall in i SQL-frågor.

Man kan också titta på parametriserade sql-frågor, men det kan ju vara nästa steg.

tal = Clng(Request.QueryString("UserId"))
sträng: fixbug(Request.Querstring("text"))

Blir lite förvirrad nu.
Så det här skulle vara korrekt?

Set ObjRS = ObjConn.Execute("SELECT * FROM medlemmar where id="& fixbug(Request.Querystring("userid") &""))

Jeppeweb skrev:

Blir lite förvirrad nu.
Så det här skulle vara korrekt?

Set ObjRS = ObjConn.Execute("SELECT * FROM medlemmar where id="& fixbug(Request.Querystring("userid") &""))

Nej, det är bara Querystringen som ska in till fixBug(). Det är ju bara i den delen du inte vet vad det står...

Set ObjRS = ObjConn.Execute("SELECT * FROM medlemmar where id="& fixbug(Request.Querystring("userid")) &"")

(Flyttat ett ')'.)

För ni säger olika, voigtann, Clng på Userid, och @nders, fixbug på Userid..

Gah.

Jeppeweb skrev:

För ni säger olika, voigtann, Clng på Userid, och @nders, fixbug på Userid..

Gah.

Kolla ovanför ditt citerade inlägg. :)

vo1gtanns förslag var att du skulle hantera siffror på ett sätt och strängar på ett annat. MEN då måste du först veta att användaren skrivit in en siffra där du förväntar dig det. Vilket blir ytterligare en koll... som måste in före. (Såvida inte Clng fixar biffen om det kommer in en sträng? Jag kan inte ASP.) Så det blir enklare att behandla allt som strängar. Dock är du inte lika säker på att du får in vettig indata.

MySQL blir inte glad om den får fel typer att jämföra med... Så du riskerar databasfelmeddelanden om man kan stoppa in en sträng där det borde vara en siffra. (Tror jag... själv kollar jag om det är siffror där det ska vara det...)

Nej.. jag säger att Om det är ett tal så Kontrollera/konvertera det till ett tal. Och Fixbug använder du på strängar. Jag har ingen aning om ditt UserId är ett tal eller inte.. jag kan bara gissa att det är ett tal. Jag kan ha fel.

Den kommer att crashar men din databas är iallafall inte öppen mot "attacker".

Okej.

Hur ska det här se ut då?

<%
Set ObjRSCheckit = ObjConn.Execute("SELECT * FROM visitors WHERE fromid="& CLng(Session("id")) &" AND tillid="& CLng(ObjRS("id")) &"")
%>

Alla Querystringar ska bytas ut som du skrev aasah, då är jag någorlunda skyddad eller?

Syftet är ungefär detsamma. Tänk efter lite vad koden gör.
Clng konverterar någonting till ett tal. Skickar man in en konstig sträng kraschar den typkonverteringen och sql-frågan ställs inte - därmed är användarid-variabeln säkrad.
Fixbug-funktionen escapear apostrof-tecken och gör därmed så inte elaka människor kan kapa dina SQL-frågor.

Det är inte heller fel att göra både typkonvertering och escape:a strängar.

Det finns hur mycket vettigt som helst att läsa så man förstår hur och varför. Börja till exempel på wikipedia och följ länkarna där.

Jeppeweb skrev:

Alla Querystringar ska bytas ut som du skrev aasah, då är jag någorlunda skyddad eller?

Ta till dig det @nders skrev, och ja - så fort du plockar in info som en användare på något sätt har tillgång till i en SQL-fråga, måste du säkra indatat.

"Info som en användare på något sätt har tillgång till" inkluderar Querystring och Cookies.

Okej, tack då är jag någorlunda med känner jag.

ObjConn.Execute("UPDATE medlemmar set online='0' where anvnamn='" & fixbug & ObjRS("anvnamn") &"'")

Är det där korrekt?

njäe... Funktioner kallar du ju på med parenteser.

ObjConn.Execute("UPDATE medlemmar set online='0' where anvnamn='" & fixbug(ObjRS("anvnamn")) &"'")

Jaha, okej. :)
Du tyckte jag borde bytta namn på fixbug också? Why's that?

Hur står hashning/kryptering utav lösenord på en skala utav säkerhet? Är det jättebra att ha?

Fixbug säger inte så mycket vad den gör... fix what bug? SecureSqlString eller något liknande kanske?
Kryptering är alltid bra för dina användare. Du får utveckla lite vad du menar med det? Vill du kryptera all data så måste du på något sätt kunna backa tillbaka datan igen. Lösenord / Personnummer osv är aldrig bra att lagra i klar text.

Jeppeweb skrev:

Du tyckte jag borde bytta namn på fixbug också? Why's that?

För att jag hatar funktioner som är felaktigt namngivna. Funktionen fixar inga buggar överhuvudtaget, utan säkrar input till SQL-frågor. Funktionen kanske skulle kunna heta EscapeStringForSQL eller SQLSafe om man vill ha lite kortare namn.

Okej, jag hade tänkt att kryptera lösenord. Ska fixa det.

Okej, har döpt om fixbug till SQLSafe på @nders begäran. Du har rätt, det klingar bättre. :)

Uppskattar verkligen hjälpen man får här.