HTML/PHP - tillåt endast siffror och : (kolon) i fält

http://www.thimbleopensource.com/tutorials-snippets/jquery-pl...
http://stackoverflow.com/questions/995183/how-to-allow-only-n...

Men du kommer ju behöva verifiera resultatet när det submittats i ditt script.

När det gäller tidsstämplar och datumkontroller så är det många som försöker uppfinna hjul om och om igen, när det redan finns väldigt många inbyggda funktioner som tar hänsyn till väldigt många saker. Att tolka datum manuellt är aldrig bra.

Om du vill kontrollera att det är en giltig tidssträng så kan du i PHP i detta fall med fördel använda strptime(). Du ger funktionen två argument: tidssträngen och dess tänkta tolkning, och om tidssträngen inte är en giltig tidsstämpel enligt mönstret så returneras false. Exempelvis strptime("10:61:14", "%H:%M:%S") → false, men strptime("10:59:14", "%H:%M:%S") → [array med datumet, vilket tolkas som true i PHP].

Så i praktiken:

if (strptime($tidsstampel, '%H:%M:%S')) {
    //Datum OK
}
else {
    //Datum inte OK
}

Precis, det är alltid klurigt att parsea tid själv .

I HTML5:

<input type="text" required pattern="([0-1][0-9]|2[0-3])(:[0-5][0-9]){2}">

Detta tillåter bara giltiga "HH:MM:SS"-format. Kombinera detta med strptime() i PHP som jag nämnde ovan så ska det vara klart.

Och se till att dokumentet tolkas som HTML5, så klart.

Notera återigen det som nämndes tidigare att vad gäller klientsidekontroller som denna så finns det inget som säger att klienten faktiskt måste lyda. Exempelvis en browser som inte implementerat denna funktion i HTML5 kommer ju bara ignorera HTML5-specifikationen, så PHP-kontrollen på serversidan måste göras. Klientkontroller är bara ett hjälpmedel för just klienten, egentligen.

Notera att "required" och "pattern" är separata attribut. Det är alltså inte "required pattern", så att säga. Ett enstaka attribut i HTML innehåller aldrig ett mellanslag.

I XHTML så hade man skrivit

required="required" pattern="..."

men man behöver inte sätta liknande värden på attribut som inte behöver några sådana i korrekt HTML.

Så ditt problem löses helt enkelt genom att inte skriva "required" men ha kvar "pattern". Då kan användare läman fältet blankt, men om de skriver något så måste det stämma med "pattern".

(Notera att jag redigerade mitt mönster lite efter att jag först postat det; ser att du citerat när det gamla fortfarande stod kvar. Båda fungerar, men det andra är lite kortare. Kanske kan vara belysande att titta på skillnaderna för att se vad mönsterna betyder, och då kanske även enkelt se hur man löser din andra fråga: hur man tillåter värdet "X" också.)

<input type="text" name="Date" pattern="([0-9,X]{4}-[0-9,X]{2}-[0-9,X]{2})">

"," ska du inte ha med, för nu är det ett giltigt tecken att skriva in. Så som du har skrivit så är även t ex "7,XX-X8-00" giltig input, men inte ett speciellt bra datum.

Ekvivalent med ditt exempel men enklare:

<input type="text" name="Date" pattern="(XXXX-XX-XX|([0-9]{4}(-[0-9]{2}){2}))">

Med lite hänsyn tagen till att vi bara vill ha giltiga datum:

<input type="text" name="Date" pattern="(XXXX-XX-XX|([0-9]{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])))">

Ingen månad har 0 eller >32 dagar, inget månadsnummer är 0 eller >12. Vi går inte "all-in" och kontrollerar att man inte anger t ex 31 april, men skulle man gå så långt så skulle man även kunna titta på skottår och mängder med specialregler, så detta är en rimlig begränsning. Likaså att vi håller oss e Kr och innan år 10000.

Men det låter jobbigt att de ska behöva skriva "XXXX-XX-XX" för att ange att de inte har något datum, men ändå inte vill att det ska anges som dagens datum. Lättare är att låta de skriva bara "-" för detta ändamål. Exempel:

<input type="text" name="Date" pattern="(-|([0-9]{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])))">

Sköt hanteringen av strängen "-" specifikt i PHP-koden.

<input type="text" name="Date" pattern="(-|[0-9X]{4}-[0-9X]{2}-[0-9X]{2})">

OK, jag trodde du antingen ville att de skulle kunna skriva ett datum, men om de inte visste så skulle de bara skriva "-". Men du vill att de ska kunna ange t ex "2012-01-XX" ifall de vet att det var i januari, men inte vet vilken dag?

Som du skriver ovan skulle ju t ex mönstret "X01X-X8-3X" passa, och även "2013-99-00", och det är ju lite skumt. Skulle det vara OK att de antingen får ange "(exakt år eller inget alls)-(exakt månad eller ingen alls)-(exakt dag eller ingen alls)"?

Isf skulle jag kanske mer rekommendera

<input type="text" name="Date" pattern="([0-9]{4}|XXXX)-(0[1-9]|1[0-2]|XX)-(0[1-9]|[12][0-9]|3[01]|XX)">

Nu skulle de kunna ange t ex "XXXX-XX-07" osv vilket också är konstigt.

Kanske du framför allt skulle göra en select-meny med år, månader och dagar och kanske javascriptkontroll på vad som är rimligt. "pattern"-attributet lämpar sig bäst när man faktiskt har ett bestämt mönster som input ska vara, men när komplexiteten drar iväg så är det fel verktyg för uppgiften. Fundera också på om du inte lika gärna skulle kunna ha enkla select-menyer för år, månad, dag med färdigifyllda rimliga värden.

 <input type="text" name="Date" pattern="([0-9]{4})-(0[1-9]|1[0-2]|XX)-(0[1-9]|[12][0-9]|3[01]|XX)">

 <input type="text" name="Date" pattern="([0-9]{4})-(0[1-9X]|1[0-2X]|XX)-(0[1-9X]|[12][0-9X]|3[01X]|XX)">

Det finns inget att egentligen "exploita", eftersom den "riktiga" kontrollen ska ske genom PHP, eftersom det är här som datumangivelsen faktiskt måste behandlas. Kontroller på klientsidan är egentligen bara en smidighetsfaktor för användaren, så att den inte ska behöva skicka iväg en förfrågan som ändå inte kommer godkännas av servern.

Ditt sista mönster tillåter inte att man anger "wildcards" för årtalet, t ex "201X-XX-XX", eller ens "XXXX-XX-XX" vilket väl var första anledningen till att inte bara använda ett vanligt datummönster, men däremot tillåter den märkligheter som "2012-XX-31"

Om man vill göra som du vill här så behöver man ett mönster som behandlar varje "wildcard" för sig, dvs antingen är alla tecken "X", eller så är alla tecken utom det första "X", eller så är alla tecken utom de två första "X", eller… Det går snabbt att skriva från tidigare regler med lite copy-paste:

<input type="text" name="Date" pattern="(XXXX-XX-XX|[0-9]XXX-XX-XX|[0-9]{2}XX-XX-XX|[0-9]{3}X-XX-XX|[0-9]{4}-XX-XX|[0-9]{4}-[01]X-XX|[0-9]{4}-(0[1-9]|1[12])-XX|[0-9]{4}-(0[1-9]|1[12])-[0-3]X|[0-9]{4}-(0[1-9]|1[12])-(0[1-9]|[12][0-9]|3[01]))">

Det är väldigt rättframt att skriva ett sådant mönster om man förstår paranteserna och |-tecknets roll. Ovanstående ska inte vara några problem att läsa, utöver att det är långt.

Vill du som i ditt sista exempel inte tillåta wildcards i årsangivelsen så kortas det ner till t ex:

<input type="text" name="Date" pattern="([0-9]{4}-XX-XX|[0-9]{4}-[01]X-XX|[0-9]{4}-(0[1-9]|1[12])-XX|[0-9]{4}-(0[0-9]|1[12])-[0-3]X|[0-9]{4}-(0[0-9]|1[12])-(0[1-9]|[12][0-9]|3[01]))">

Eftersom du inte kommer använda ett standarddatumformat, utan tillåta wildcards, så kommer PHP-kontrollen också bli klart mer invecklad istf att bara kolla om det är ett giltigt datum.

I praktiken kanske det är skumt att öht tillåta partiella wildcards i t ex månads/datumsangivelse av typen "2012-1X-XX" och "2012-12-2X". Mer konsekvent vore att antingen ange korrekt månad eller ingen alls, och korrekt dag eller ingen alls. Då kan ett mönster vara:

<input type="text" name="Date" pattern="[0-9]{4}-(XX-XX|((0[1-9]|1[12])-(XX|(0[1-9]|[12][0-9]|3[01]))))">

Detta tillåter datum på formen "2013-02-25", "2013-02-XX", "2013-XX-XX" men inga övriga varianter (utöver helt blankt).

Återigen så är select-formulär troligen enklare. Att det tar längre tid att fylla i är en sanning med modifikation: det tar lika många knapptryckningar att markera första rullistan och trycka "2013<Tab>02<Tab>25" (eftersom alla (?) browsers söker automatiskt i markerad rullist om man trycker på tangenter) som att markera textfältet och trycka "2013-02-25". Det tar färre knapptryckningar att skriva "2013<Tab><Tab>" än "2013-XX-XX".

http://tools.netshiftmedia.com/regexlibrary/#

Där kan du kolla om din regex funkar i realtid - Helt oumbärligt för oss icke-savanter som inte kan läsa regexp som en bok.

<input type="text" name="Date" pattern="[0-9]{4}-(XX-XX|[1-9]X|X[1-9]((0[1-9]|1[12])-(XX|[1-9]X|X[1-9]|(0[1-9]|[12][0-9]|3[01]))))">

Varför vill du att det ska funka? Vill du täcka in fallen när användare vill ange:

• –Jag vet att jag gjorde det på en månad som slutar på 1, men minns inte om det var januari eller november.

• –Jag vet att jag gjorde det på en dag som slutade på 3, men inte om det var den tredje, trettonde eller tjugotredje.

• –Jag vet att jag gjorde det på en månad som börjar på 1 och en dag som börjar på 3, men inte om det var 10–31, 11–30, 12–30 eller 12–31.

Det är ju nonsensinput . Hur ska du kunna sortera på datum? Låter som en ogenomtänkt designidé som du kommer märka är dålig när du ska börja försöka hantera data på serversidan.

Ja, det är nu du får skörda att ditt datumformat inte är speciellt konsekvent . "XX" är ju ingen korrekt varken månads- eller dagsangivelse enligt något vettigt datumsystem. Du får göra en egen variant som verifierar formen på indata iom att du tillåter inkompletta datumangivelser.

htmlentities på strängen som ska lägga in i databasen brukar vara bra:

http://us2.php.net/htmlentities

Det är ett starkt tecken på att du inte gör saker "korrekt" . Jag ser i kristallkulan att du just nu kör en databasfråga direkt på användarens indata, utan att kontrollera att den inte innehåller skadlig kod (se xkcd). Du måste ha kontroll över indata i koden, annars ligger din applikation öppen för attacker. Automatiserade script på datorer världen över spenderar dag och natt med att testa alla sidor de kan hitta via sökmotorer och annat, så det är bra att inte lämna saker alltför enkla att ta över, och det är lätt att göra några första kraftfulla skyddande steg.

Till att börja med: databasfrågor bör inte gå genom `mysql`-modulen (som jag även det i kristallkulan kan se att du använder), utan `mysqli` som använder s k prepared statements. Detta ger prestandavinster (i små fall knappt märkbara) men framför allt ett gränssnitt till MySQL där databasen har en chans att veta vad som är tänkt att vara indata och vad som är querysyntax. Korrekt användning av mysqli kommer automatiskt göra att risken för SQL-injektion elimineras (så länge det används i närheten av korrekt). PHP:s dåliga säkerhetsrykte hade fått sig en ordentlig skjuts uppåt om de inte bara gjort `mysql`-tillägget "utdaterat" utan även tagit bort det helt, men samtidigt så hade de väl förlorat många användare. Det kan argumenteras för att det sistnämnda borde varit att föredra (och det verkar som att de faktiskt förbereder sig för att ta bort `mysql` helt till förmån för `mysqli`, men tidsplanen är lite oklar). Se gärna How to prevent SQL injection in PHP?

Om du använder `mysql`-tillägget så får du i stället åtminstone se till att jobba med input sanitizing, dvs se till att den data du kör i dina databasfrågor inte innehåller skadlig kod. En vanligen använd funktion i PHP för detta i samband med databaser är mysql_real_escape_string() (som dock allena ej är komplett ur säkerhetssynpunkt — se den högst rankade kommentaren på detta svar). Men som sagt: använd `mysqli` i stället, då säkerheten där kommer "på köpet" i stor utsträckning.

Utöver dessa rena SQL-baserade säkerhetsaspekter så behöver du skydda dig från XSS. Om du någonstans skriver ut data som en användare angivit så får du se till att den inte kan tolkas som HTML/JS/etc.-kod. På allt du skriver ut till dokumentet från osäkra datakällor (användares input är osäker i sammanhanget) så ska du slänga på ett htmlspecialchars() på strängen (men akta dig extra noga om du skriver ut användardata inuti en HTML-tagg, likt `<img src="<?php echo $anvandarens_egen_avatar_url;?>">`).

Och som om inte detta vore nog så behöver du även göra validering av input. Om du tar in ett värde från användaren och förväntar dig att det ska vara ett heltal: gör en (int)-typkastning på värdet (och hantera fallet då det inte går). Om du förväntar dig att det ska vara ett datum, kontrollera detta (både att det är på formen du önskar, samt att det är ett giltigt datum).

Säker webbprogrammering handlar mycket om att veta vad man får in, och veta vad man skriver ut. Om man arbetat fram den reflexen så är mycket vunnet.

Just nu använder du den utdaterade modulen som heter Original MySQL API i PHP för att kommunicera med databasen MySQL.

I stället rekommenderas det att du använder modulen MySQLi för att kommunicera med databasen MySQL (eller PDO_MYSQL som är liknande).

Redan i PHP-manualens introduktionsavsnitt för den gamla MySQL-modulen så står det:

Ett praktiskt exempel (inte fullständigt, inte ämnat för produktion, nätet svämmar över av mer utförlig information om skillnaderna mellan API:erna):

I stället för att du med det gamla API:t skriver en textsträng och kastar den rakt in i MySQL:s innersta via

// OBS! Exempel på hur en databasfråga INTE ska se ut:
mysql_query('UPDATE tabell SET namn="'.$_POST['namn'].'", alder="'.$_POST['alder'].'" WHERE id='.$_POST['id']);

så bör/kan/ska man med MySQLi skriva likt (rikligt kommenterat):

// Definiera för MySQL vad som är frågestruktur och vad som är indata. Indata
// markeras med placeholder '?'.
$query=$mysqli->prepare('UPDATE tabell SET namn=?, alder=? WHERE id=?');
// Definiera vilka datatyper som ska skickas in och vilka som är motsvarande
// PHP-variabler (s=sträng, i=integer=heltal).
$query->bind_param('sii', $_POST['namn'], $_POST['alder'], $_POST['id']);
// Nu har MySQL hunnit förbereda sig och frågan körs inte förrän nu med ett
// enkelt:
$query->execute();
// Om vi inte ska använda denna fråga mer så kan vi för ordnings skull köra
// (detta körs när PHP är klar med sidan likväl, kan nämnas)
$query->close();

MySQL kommer här "kompilera" queryn och förbereda sig för att ta emot själva frågan för att sedan köra den med "execute". Om många rader ska behandlas så snabbar detta upp saker då samma kompilerade fråga kan återanvändas (enkelt sagt; i praktiken hjälper cachefunktioner till med detta även om man inte själv säger till). Den stora fördelen är dock för de flesta bara att det nu är definierat vilka datatyper som ska in i vilka fält, om de inte stämmer så säger PHP till, och SQL-injektion är avvärjt (om man inte gör något särdeles dumt).

För att visa på sårbarheter som det första "dåliga" sättet att skriva på öppnar: låt säga att en användare i namnfältet skrivit

kalle", losenord="hej

och kanske gjort en egen POST-request med id-fältet

1 OR 1=1

Om du använder MySQLi så kommer namnet helt enkelt sättas till den strängen (inget säkerhetshål), och om `id`-fältet inte var ett heltal så skulle PHP säga till och stoppa transaktionen.

Om du skrivit som i det första naiva fallet ovan med gamla API:t så skulle användaren dels kunna ändra lösenordet genom en sidomekanism, och även möjligen (exemplet var bara en prototyp för att illustrera idén) ändra allas namn och lösenord till kalle:hej. Vad detta i praktiken gör beror på sidan i övrigt, men vi kan alla hålla med om att det inte är önskvärt.

Om det handlat om en DELETE-sats så skulle "1 OR 1=1"-liknande `id`-fält kunna rensa hela databasen.

Om det handlat om en SELECT-sats så skulle det kunna få allas uppgifter att skrivas ut till den som gjorde requesten, inklusive lösenord om de även gjorde en variant likt den i namnfältet för att påverka ytterligare fält.

Det var enkla exempel på SQL-injektion (kanske för enkla i praktiken, men de är som sagt bara tänkta att illustrera idén). För att ha ett någorlunda acceptabelt skydd med det utdaterade MySQL-API:t så skulle man kanske i stället skriva:

$namn = mysql_real_escape_string($_POST['namn']);
$alder = (int)$_POST['alder'];
$id = (int)$_POST['id'];
mysql_query('UPDATE tabell SET namn="'.$namn.'", alder='".$alder.'" WHERE id='.$id);

Några observationer angående detta sätt:

• det blir lika mycket att skriva i detta enkla exempel, betydligt mer om frågan är mer komplicerad (mer indata)

• det blir mindre tydligt vad som faktiskt händer i databasfrågan (i mer komplicerade exempel är detta ett reellt problem)

• prestandan blir sämre än med prepared statements

• extra tid och kod behöver tillbringas på att kontrollera indata och om man gör något fel här så öppnar man för attacker (hint: alla gör någon gång något fel här).

Är man "van" vid det gamla och snart försvunna sättet så kan det kännas bökigt att byta (det tyckte jag när jag först uppmärksammades på problematiken), men snabbt märker man att det nya sättet snarare tjänar tid, är mycket mer överblickbart och man kan sova bättre om nätterna; dels av säkerhetsskäl, men även då man inte riskerar att vakna upp och se att PHP tagit bort stödet för det gamla MySQL-API:t.

Som sagt: internet har mängder med mer information. Läs t ex de länkar till Stack Overflow som jag gav i förra posten för lite inblick. Fler länkar:

• Do htmlspecialchars and mysql_real_escape_string keep my PHP code safe from injection? [SO]

• how safe are PDO prepared statements [SO]

• PHP tutorial that is security-, accuracy- and maintainability-conscious? [SO via archive.org]