Nee, daar bedoel ik
zoiets mee. Functies die per definitie op alle input mysql_real_escape loslaten (of erger: mysql_real_escape + htmlentities + addslashes of weet ik het
)
Dan, en don't get me wrong, ik bdoel 't niet lullig, ga daar dan ook geen advies aan anderen over geven
Ook dat durf ik te betwijfelen
Het zal niet voor 't eerst zijn dat mensen er niet bij stil staan dat een $_COOKIE['somekey'] ook escaped (kan) moet(en) worden of zelfs een $_SERVER['somekey']. Dat heb ik niet 1, niet 10, niet 100 maar wel 10^6 keer gezien
En dan heb ik 't nog niet eens over data uit andere bronnen (3rd parties) etc.
Ik heb 't over (My)SQL, RTF, HTML, CSV, URL's, Emails (Base64, quoted printable), JSon, Javascript, XML en ga zo maar door. Elk van deze (en vele andere) zaken heeft wel ergens met escaping/encoding te maken, de een gestandaardiseerd, de ander (bijv. CSV) niet.
Daar hoef je geen artikeltje over te lezen
Als je een 'functie' hebt waar je een $_POST in flikkert en daarna aanneemt dat alles wat in $_POST zit "veilig" is of iets met een dergelijke strekking elders op 1 van de voorgenoemde zaken toepast dan moet je
dat vooral
niet doen
Zoals ik zei: escapen/encoden/... doe je afhankelijk van de context en dus context-aware.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| $myvar = "Welcome to <b>Joe's diner</b>";
//MySQL:
$query = 'insert into `mytable` (content) values (' . mysql_real_escape_string($myvar) . ')';
//MySQL (parameterized query):
$query = 'insert into `mytable` (content) values (@:mycontent)';
$something->parameters['mycontent'] = $myvar;
//PostgreSQL:
$query = 'insert into `mytable` (content) values (' . pg_escape_string($myvar) . ')';
//JS:
var title = <? echo json_encode($myvar); ?>
//JS voor 'weergave':
<p>...blah blah... <? echo htmlentities(json_encode($myvar)); ?> ...blah blah...</p>
//HTML:
<p>You searched for: <i><? echo htmlentities($myvar); ?></i>
//HTML wanneer HTML is toegestaan:
<h1><? echo $myvar; ?></h1>
//Shell:
system('echo ' . escapeshellarg($myvar));
...
//etc. etc. |
Het is niet heel moeilijk, je moet gewoon
weten waar je
mee bezig bent Als je het idee achter (bijv.) een
SQL injection begrijpt (en dus niet gewoon domweg braaf escaped, maar echt
snapt wat er gaande is) dan is het niet moeilijk dat door te trekken naar
XSS en
andere vormen.
Je snapt, als je naar bovenstaande ((deels)pseudo) code kijkt dat 't stom is op per definitie $myvar te html-escapen want voor 'tzelfde geld heb je de waarde verderop nog nodig in een andere context; dan moet je daar weer eerst gaan htmldecoden om 't vervolgens op een andere manier weer te escapen.
Escapen doe je
eigenlijk alleen maar wanneer dat nodig is ('last moment'); daar waar je je bewust bent van de context waarin de waarde gebruikt wordt. Als je een naam in je DB wil opslaan dan gebruik je daarbij geheid een mysql_real_escape_string of iets dergelijks, maar bij 't opslaan gebruik je nog géén htmlspecialchars/htmlentities. Maar, RobIII, dat is toch handig? Dan vergeet ik straks als ik een echo ergens doe de htmlspecialchars/htmlentities te doen!! Ja, en wat nu als de naam niet gebruikt wordt in een HTML pagina maar, bijvoorbeeld, bij het afdrukken van een enveloppe? Wat zou de ontvanger er van vinden als de brief gericht is aan
C&A i.p.v. C&A?
De htmlspecialchars/htmlentities gebruik je dan weer wél wanneer je een webpagina gebruikt waar de gebruikersnaam wordt weergegeven:
<?php echo 'Welkom terug, ' . htmlentities($name) . '!!'; ?>
[
Voor 30% gewijzigd door
RobIII op 28-09-2011 22:25
]
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
/u/253667/photo-thumb-398464.png?f=community)
:strip_icc():strip_exif()/u/43400/avatar.jpeg?f=community){kind=avatar}
Wat je ziet is 
:strip_exif()/u/325880/avatar.gif?f=community){kind=avatar}