Hvordan bruges htmlspecialchars()? Til fx $_POST, $_GET og input felter?

htmlspecialchars() bruges ikke til input men kun til output.

med hensyn til valifdering af email adresse, saa kan man lave et hurtigt convenience check paa om det er noget @ noget med mindst et punktum.

Bedre checks kraever at man sender en email med et confirmation link.

Hvordan gøres dette?

Og kan man så ikke sætte htmlspecialchars om mine $_POST variabler?

Hvis du bruger htmlspecialchars paa dit inout, saa gemmer du HTML i databasen, hvilket er et meget skidt design.

Findes der en PHP funktion der kan tjekke om brugeren fx skriver en e-mail? Har forsøgt at google mig frem til det, men har ikke kunne få det til at virke :(

Det er ret almindeligt at bruge regex til det.

Men det er som sagt langtfra et sikkert test.

Hvad kunne man i stedet som en sikker test?

Kan man ikke bruge htmlspecialchars til at rense et brugerinput for SQL-injections? Fx ved at sætte det rundt om alle sine $_POST variabler? Se eksempel:

$type = htmlspecialchars($_POST['type']);

Nej. 

htmlspecialchars haandterer ikke altid single quotes.

#8
Hvorfor vil du, til hver en pris, bruge htmlspecialchars? Vil du undgå SQL-injection så brug PDO eller mysqli API og prepared statement. Tror du ikke du tænker på mysql_real_escape_string() når du nu snakker om SQL-injection? Men det er stadig ikke nok :o(

Det vil jeg bestemt heller ikke. Jeg har bare forstået det således at man kan bruge det til beskytte af sin hjemmeside (med brug af database), mod folk der kan manipulerer med SQL-injections til fx uautoriseret administratoradgang, hvor man har et databasekald, som fx når et bruger indtaster oplysninger til oprettelse af en bruger, eller logger ind.

Jeg har til en hjemmeside brugt en PDO forbindelse i en separat fil (connect.inc) (Hjemmesiden er et eksamensprojekt). Denne henter jeg senere hver gang jeg laver et database kald.

require_once('connect.inc.php');
$conn = dbConnect('pdo') or die('no connection');

Men gør også brug af mysqli (når en bruger logger ind) og mysql(til at oprette indhold med brug af en dropdown bar hvor data hentes med mysql_connect og msql_fect_array) extensions.

Jeg aner faktisk intet om validering og database-sikkerhed, vil bare gerne tage højde for det i mit projekt. Har brugt en sha1 til beskyttelse af kodeord fx. Har derudover hørt om SQL-injections og læste man skal "rense" brugerinput og troede htmlspecialchars blev brugt til dette, på sine $_POST og $_GET.

htmlspecialchars har absolut intet med beskyttelse af input mod SQL injection at goere.

Det er en funktion du kan bruge hvis du i output vil have vist HTML kode ufortolket.

SHA1 er ioevrigt ogsaa foraeldet. Brug SHA-256.

Mange tak for dine svar arne_v, kan du lægge et svar så kan jeg give dig pointene?

Hvilke forhold kan en udvikler tage for at undgå at blive offer for et SQL injection-angreb. Hvordan renser jeg ALT input hvad der nu måtte være farlige tegn. Hvilke specialtegn bør jeg filtrerer helt fra, eller konvertere (escapes - og hvordan gør man det?), så de ikke behandles aktivt, men bliver gemt, som det tegn de repræsenterer?

svar

Du beskytter dig mod SQL injection ved konsekvent at bruge prepared statement.

Derudover boer du generelt ogsaa validere input og checke alt for om det har det rigtige format (fordi udover SQL ibjection er der ogsaa XSS og andre grimme ting).

Test v.h.a. regex ses hyppigt brugt til at validere input med.

Er det korrekt, hvis man bruger PDO, at man sikrer sig mod SQL-injections?

Og hvis man bruger mysqli at man så kan bruge "mysql_real_escape_string" for at undgå SQL-injections?

2 x nej

Man beskytter sig mod SQL injections med PDO og mysqli extensions ved at bruge prepared statements. Det er nemt og naturligt, men man kan stadig snige en parameter konkatanering ind hvis man vil.

Man beskytter sig mod SQL injuections i mysql extension ved at bruge mysql_real_escape_string. Og det kraever lidt omtanke at faa detr gjordt korrekt.

Igen mange tak for dine svar arne_v, jeg beklager for min uvidenhed, men brænder for dette og er derfor meget interesseret i forstå det korrekt og lære så meget som muligt.

Men vil prøve at kigge mere på disse prepared statements, hvis jeg forstå det korrekt, kun er til brug med mysqli og PDO?

All moderne database API'er har prepared statements (Microsoft kalder dem for parameters).

PDO og mysqli extensions er moderne. mysql extension er ikke moderne.

Et hurtigt check viser at OCI (Oracle), DB2 og pgsql (PostgreSQL) alle har prepared.

arne_v når du skriver "Hvis du bruger htmlspecialchars paa dit inout, saa gemmer du HTML i databasen, hvilket er et meget skidt design." - hvordan kan det være at det er skidt design?

Fx ved at gøre således ligesom nedenstående eksempel:

"$type= htmlspecialchars($_POST['animaltype']);
$name= htmlspecialchars($_POST['animalname']);
$age= htmlspecialchars($_POST['animalage']);       
$descr= htmlspecialchars($_POST['animaldescription']);
$foto= htmlspecialchars($_POST['animalfotourl']);
$date=htmlspecialchars($_POST['animalhomelessdate']);



$sqlquery  = "INSERT INTO animals_tbl(animaltype, animalname, animalage, animaldescription, animalfotourl, animalhomelesssince) VALUES (':type',':name',':age',':descr', ':foto', ':date')";
   

$stmt = $conn->prepare($sqlquery);
$stmt->bindParam(':type',$type, PDO::PARAM_STR);
$stmt->bindParam(':name',$name, PDO::PARAM_STR);
$stmt->bindParam(':age',$age, PDO::PARAM_INT);
$stmt->bindParam(':descr',$descr, PDO::PARAM_STR);
$stmt->bindParam(':foto',$foto, PDO::PARAM_STR);
$stmt->bindParam(':date',$date, PDO::PARAM_STR);

$stmt->execute();"

Man gemmer data i en database ikke praeformateret output.

Det er godt design at kunne genbruge de samme data for forskellige output formater.

PC browser----(HTML 4)-----web app----database
PC browser----(XHTML 1)-----web app----database
PC/smartphone browser----(HTML 5)-----web app----database
PC/smartphone browser----(XHTML 5)-----web app----database
PC/smartphone browser----(JSON)-----AJAX web app----database
PC/smartphone browser----(XML)-----AJAX web app----database
smartphone app----(JSON)-----web service----database
smartphone app----(XML)-----web service----database
desktop app----(XML)-----web service----database
desktop app----(binary)-----service----database
server----(XML)----web service----database
server----(SOAP XML)----web service----database

Men er det ikke en anerkendt metode at bruge htmlspecialchars til sanitering?

http://en.wikipedia.org/wiki/HTML_sanitization
"HTML sanitization is the process of examining an HTML document and producing a new HTML document that preserves only whatever tags are designated "safe". HTML sanitization can be used to protect against cross-site scripting and SQL injection attacks by sanitizing any HTML code submitted by a user."

Så ved udtræk og præsentation på klient-siden vil html-kode ikke blive fortolket af browseren med i stedet stå blot som ufortolket kode?

Så kan stadig ikke helt følge dig hvorfor det er skidt design?

Har også læst mig frem til dette på stackoverflow:
http://stackoverflow.com/questions/414366/html-sanitization-bad-markup
"A method to sanitize any potentially dangerous tags from the provided raw HTML input using a whitelist based approach, leaving the "safe" HTML tags."

htmlspecialchars bruges hvis du vil have vist HTML fremfor at faa det fortolket

<b>xxxx</b>

viser f.eks. tags fremfor at bolde teksten.


En feature som er mest relevant paa programmerings web sites.

----

HTML sanitizing er en god ting, men htmlspecialchars() goer at de farlige ting vises som ufarlig tekst - i de fleste tilfaelde vil man foretraekke at faa dem helt vaek.

Har du laest og taenkt over #27 ?

Ja, men forstår det desværre ikke rigtig?

Hvis du har noget data i din database og det skal sendes til en gammel browser som HTML, som JSON til en nyere browser og som XML til en smartphone app er det saa smart at gemme data med HTML formatering?

Det lyder det ikke som. Men forstår ikke rigtig hvorfor du snakker om JSON og XML?

Hvis man fx har et mini-cms CRUD webløsning, hvor brugere kan skrive nyheder og besøgende kan kommenterer, denne bliver lavet med HTML bliver det så fortolket som JOSN, XML og ikke HTML på andre platforme?

Har aldrig arbejdet med disse JOSN og XML.

*Og her tænker jeg den er lavet med HTML5

Der sker ikkke noget automatisk.

Men hvis du vil omskrive dit CMS til at bruge AJAX vil du typisk lade JavaScript hente i JSON eller XML format.

Hvis du vil lave en smartphone app til dit CMS (jeg er ikke sikker paa at det giver mening , men ...) saa vil du ogsaa typisk hente i JSON eller XML.

Ja okay, nu forstår jeg hvad du mener. Så er det måske en god ide bare helt at fjerne disse tegn helt, for vil selvfølgelig ikke have HTML'en fortolket i mine input og heller ikke have dem vist. Kender du tilfældigvis en metode til dette?

Men man kan vel bruge htmlspecialchars til output og beskytte sig mod XSS på den måde?

Generelt er det bedre at tillade det gyldige fremfor at forbyde det ugyldige.

Saa det er bedre kun at acceptere bogstaver til et navn end det er at forsoege at strippe HTML ud.

htmlspecialchars vil forhindre JS i at blive koert men alle vil kunne laese den JS - det ser ikke saa smart ud

Så det ville være bedre at bruge fx http://htmlpurifier.org/? Som jeg har forstået det er en whitelist over det tilladte?

Hvis der skal tillades HTML saa JA.

Et CMS vil maaske tillade HTML men mange andre web apps behover ikke tillade HTML.

Der kan man saa bare validere op imode noget regex som definerer hvad der er tilladt.

Mange tak igen, jeg tror jeg begynder at se det hele i en større sammenhæng nu.