abonnement bol.com Unibet Coolblue
pi_106434787
quote:
16s.gif Op donderdag 5 januari 2012 12:45 schreef GlowMouse het volgende:

[..]

geen echo
of = teken i.c.m. shorttags. :P
pi_106435272
quote:
16s.gif Op donderdag 5 januari 2012 12:45 schreef GlowMouse het volgende:

[..]

geen echo
Oeps :') Toegevoegd :@
pi_106437581
Goedemiddag,

Ik heb het volgende probleem: Ik heb een contact pagina op mijn website gezet in html, en het mail script in PHP. Geen probleem, het word gewoon verzonden en ik ontvang ook een mailtje in de mailbox. Echter, de ingevulde tekstvelden worden niet meegezonden, waardoor ik een witte mail te zien krijg. Wat doet ik fout?

Oja, vroeger nooit problemen gehad met script, maar het trad op na de verhuizing van de bestanden.
SPOILER
Om spoilers te kunnen lezen moet je zijn ingelogd. Je moet je daarvoor eerst gratis Registreren. Ook kun je spoilers niet lezen als je een ban hebt.
  donderdag 5 januari 2012 @ 14:11:37 #179
75592 GlowMouse
l'état, c'est moi
pi_106437801
Dat is raar, denk ook niet dat er zo wat over te zeggen valt. Je kunt de bron van de e-mail eens goed bekijken. Let ook op mail header injection.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_106440284
Bedankt voor de hulp allemaal, vooral die uitleg, ik snap nu wat alles is.
En ik snap dus ook wat er fout ging bij het script, ik moet dus een totaal ander script hebben.

Weten jullie of het mogelijk is zo'n script kant en klaar van internet te halen?
Of heb ik ook daar nog niet genoeg kennis voor?
Vriendlief wil wel graag een contact formulier op zn website namelijk..
  donderdag 5 januari 2012 @ 21:40:01 #181
159156 Dokay
Ago ergo sum
pi_106458952
Beste PHP devvers,

Even een vrij basale vraag. Voor mijn werkgever heb ik een php applicatie in elkaar geknutseld waarbij men intern mensen in kan roosteren en mensen extern aan kunnen geven wanneer ze beschikbaar zijn. Ziekte en verlof worden ook allemaal geregeld, iedereen blij. Alleen nu het steeds meer en meer gebruikt wordt door deze middelgrote organisatie begint mijn zorg over de veiligheid te stijgen. Laat ik eerlijk zijn: ik heb het in elkaar gezet met trail en error, heb nooit een PHP boek of cursus gedaan en met frunniken lukt me eigenlijk altijd wel wat ik wil. Maar ik weet ook dat het waarschijnlijk niet de veiligste en meest efficiente manier is.

Waar ik vooral tegen aan loop en wil vragen hoe jullie dat doen;

Als ik variabelen door minimaal 2 verschillende page's moet loodsen, gebruik ik de HTML "hidden input" tag om deze vast te houden en vervolgens weer door te zetten naar de volgende pagina die er wat mee doet.

Nou heb ik er nooit bij stilgestaan dat een kwaadwillende gebruiker deze hidden input tag kan invullen naar wens en vervolgens terug kan sturen naar de server met allerlei kwaadaardige code. In het geval van mijn appje zou dat een catastrofe zijn, want het zit bomvol met dit soort code om de eerder opgegeven waarde vast te houden.

Ik heb gepoogd om een extra SESSION aan te maken om de variable vast te houden, maar er loopt er al een van de gebruiker die ingelogd is en welke zijn ID vasthoud. Het geeft problemen als ik een tweede sessie hiernaast probeer te starten want dan wordt aangegeven dat er al een sessie loopt.

Hoe lossen jullie dit op? Alvast bedankt!
  donderdag 5 januari 2012 @ 21:50:48 #182
111382 Ofyles2
Bestemming: onbekend
pi_106459517
quote:
9s.gif Op donderdag 5 januari 2012 11:05 schreef boem-dikkie het volgende:
Dat script van die leraar trouwens. Je hele HTML echo'en. :')
Deed ik heel vroeger ook (toen ik 16-17 was), nu werk ik volgens OOP en MVC.

Liever een onderhoudsvriendelijk bulkproject dan een klein compact en onoverzichtelijk pakketje.
  donderdag 5 januari 2012 @ 22:00:35 #183
111382 Ofyles2
Bestemming: onbekend
pi_106459970
quote:
6s.gif Op donderdag 5 januari 2012 21:40 schreef Dokay het volgende:
Beste PHP devvers,

Even een vrij basale vraag. Voor mijn werkgever heb ik een php applicatie in elkaar geknutseld waarbij men intern mensen in kan roosteren en mensen extern aan kunnen geven wanneer ze beschikbaar zijn. Ziekte en verlof worden ook allemaal geregeld, iedereen blij. Alleen nu het steeds meer en meer gebruikt wordt door deze middelgrote organisatie begint mijn zorg over de veiligheid te stijgen. Laat ik eerlijk zijn: ik heb het in elkaar gezet met trail en error, heb nooit een PHP boek of cursus gedaan en met frunniken lukt me eigenlijk altijd wel wat ik wil. Maar ik weet ook dat het waarschijnlijk niet de veiligste en meest efficiente manier is.

Waar ik vooral tegen aan loop en wil vragen hoe jullie dat doen;

Als ik variabelen door minimaal 2 verschillende page's moet loodsen, gebruik ik de HTML "hidden input" tag om deze vast te houden en vervolgens weer door te zetten naar de volgende pagina die er wat mee doet.

Nou heb ik er nooit bij stilgestaan dat een kwaadwillende gebruiker deze hidden input tag kan invullen naar wens en vervolgens terug kan sturen naar de server met allerlei kwaadaardige code. In het geval van mijn appje zou dat een catastrofe zijn, want het zit bomvol met dit soort code om de eerder opgegeven waarde vast te houden.

Ik heb gepoogd om een extra SESSION aan te maken om de variable vast te houden, maar er loopt er al een van de gebruiker die ingelogd is en welke zijn ID vasthoud. Het geeft problemen als ik een tweede sessie hiernaast probeer te starten want dan wordt aangegeven dat er al een sessie loopt.

Hoe lossen jullie dit op? Alvast bedankt!
Extra sessies zijn eigenlijk ook slechts lapmiddelen.

Ik zou de gegevens gewoon controleren totdat een gebruiker zijn opdracht volledig heeft voltooid.

Dus onder andere: waarden typecasten (in een voor jouw gunstige type), reguliere expressies, htmlentities, strip_tags. Ik stel voor de controlemodellen in een aparte map op te slaan en de bestanden hierin alleen aan te roepen als het echt nodig is.

Desgewenst kun je je projectje ook naar mij toesturen als je het echt niet ziet zitten...
  donderdag 5 januari 2012 @ 22:20:03 #184
159156 Dokay
Ago ergo sum
pi_106460951
quote:
0s.gif Op donderdag 5 januari 2012 22:00 schreef Ofyles2 het volgende:

[..]

Extra sessies zijn eigenlijk ook slechts lapmiddelen.

Ik zou de gegevens gewoon controleren totdat een gebruiker zijn opdracht volledig heeft voltooid.

Dus onder andere: waarden typecasten (in een voor jouw gunstige type), reguliere expressies, htmlentities, strip_tags. Ik stel voor de controlemodellen in een aparte map op te slaan en de bestanden hierin alleen aan te roepen als het echt nodig is.

Desgewenst kun je je projectje ook naar mij toesturen als je het echt niet ziet zitten...
Bedankt voor je snelle reactie,

Ik ging ervanuit dat de gebruiker geen manier heeft om te zien wat er in een server sided sessie gebeurt, tegenover de hidden value HTML tag die vanaf de gebruikers' machine wordt verstuurd. Ik strip inderdaad al form input van ongewenste mogelijke injectie input, maar zit nog steeds met het feit dat ik weet dat de verkeerde methode gebruikt wordt om variabelen door te geven.

Wat ook moeilijk is is vanaf een initieel overzicht de waarde aan een php script doorgeven. Wat ik hiermee bedoel (voorbeeld alert..);

Ik heb een lijst met zeg 30 diensten, welk allemaal uit de database worden getrokken en onder elkaar gezet. Elke dienst heeft een unieke "id", waarmee deze word onderscheiden van andere diensten. Deze unieke dienst id word voor elke dienst opgeslagen in een bijbehorende "hidden input" HTML tag. De gebruiker kan zich opgeven voor een openstaande dienst door op de knop "Inschrijven" te drukk die naast elke dienst wordt weergeven. Tot zover goed.

Nou wil een kwaadwillende gebruiker eens het systeem in de war schoppen en besluit deze id aan te passen en wellicht al toegewezen diensten over te schrijven door een al bestaande id van een andere dienst op te geven, of het systeem te laten crashen door sql injectie code in de hidden value te plaatsen of een andere foutieve waarde.

Vraag: Hoe kan ik het systeem laten begrijpen om welke dienst het gaat die de gebruiker selecteert, maar wel dat het veilig is en dat de gebruiker er geen misbruik van zou kunnen maken?
  donderdag 5 januari 2012 @ 22:29:16 #185
111382 Ofyles2
Bestemming: onbekend
pi_106461400
In dat geval zou ik ook voor de 30 diensten een aparte MySQL-tabel maken. Het id-nummer zou ik meegeven met de URL.

Wat betreft SQL-injecties: deze kun je tegengaan door invoerwaarden te controleren en eventueel te escapen (mysql_real_escape_string).

Off-topic:

Een veel betere aanrader is PDO (hier een tutorial), waarmee je meerdere databasesystemen kunt gebruiken zonder complete codeblokken om te ploegen.
pi_106461514
quote:
0s.gif Op donderdag 5 januari 2012 22:29 schreef Ofyles2 het volgende:
In dat geval zou ik ook voor de 30 diensten een aparte MySQL-tabel maken. Het id-nummer zou ik meegeven met de URL.

Wat betreft SQL-injecties: deze kun je tegengaan door invoerwaarden te controleren en eventueel te escapen (mysql_real_escape_string).

Off-topic:

Een veel betere aanrader is PDO (hier een tutorial), waarmee je meerdere databasesystemen kunt gebruiken zonder complete codeblokken om te ploegen.
Of je verdiept je een keer in classes en bent ook per direct van het gezeik af. Dan ben je nog flexibeler :)
  donderdag 5 januari 2012 @ 22:34:23 #187
75592 GlowMouse
l'état, c'est moi
pi_106461631
quote:
6s.gif Op donderdag 5 januari 2012 21:40 schreef Dokay het volgende:
Ik heb gepoogd om een extra SESSION aan te maken om de variable vast te houden, maar er loopt er al een van de gebruiker die ingelogd is en welke zijn ID vasthoud. Het geeft problemen als ik een tweede sessie hiernaast probeer te starten want dan wordt aangegeven dat er al een sessie loopt.
Dat gaat in dezelfde sessie, je kunt $_SESSION['blahblah'] met vullen en daarna $_SESSION['user'] met wat anders.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
  donderdag 5 januari 2012 @ 22:37:09 #188
159156 Dokay
Ago ergo sum
pi_106461758
quote:
0s.gif Op donderdag 5 januari 2012 22:34 schreef GlowMouse het volgende:

[..]

Dat gaat in dezelfde sessie, je kunt $_SESSION['blahblah'] met vullen en daarna $_SESSION['user'] met wat anders.
Bedankt voor je tip, ik ga het morgen meteen uitproberen!
Is er ook een mogelijkheid om van te voren gedefinieerde waarden (welke ik nu in hidden HTML tags heb staan) veilig over te dragen tijdens de POST naar de volgende pagina..? (Behalve strip tags, eigenlijk dat er geen wijzingen in welke zin dan ook mogelijk zijn van de huidige waarde..)
  donderdag 5 januari 2012 @ 22:40:25 #189
111382 Ofyles2
Bestemming: onbekend
pi_106461910
quote:
0s.gif Op donderdag 5 januari 2012 22:37 schreef Dokay het volgende:

[..]

Bedankt voor je tip, ik ga het morgen meteen uitproberen!
Is er ook een mogelijkheid om van te voren gedefinieerde waarden (welke ik nu in hidden HTML tags heb staan) veilig over te dragen tijdens de POST naar de volgende pagina..? (Behalve strip tags, eigenlijk dat er geen wijzingen in welke zin dan ook mogelijk zijn van de huidige waarde..)
Yep.
  donderdag 5 januari 2012 @ 23:11:19 #190
25889 Sitethief
Fulltime Flapdrol
pi_106463405
Je kunt bepaalde dingen hashen, met een POST/GET meesturen en aan de andere kant checken. Dat kan natuurlijk alleen met dingen waarvan je aan beide kanten weet wat het ongeveer moet zijn, statische data dus. Andere data zou ik, mits dat niet teveel problemen oplevert via de sessie opslaan, mocht het data zijn die je langer nodig hebt dan een sessie idd in de db.
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
  donderdag 5 januari 2012 @ 23:21:54 #191
111382 Ofyles2
Bestemming: onbekend
pi_106463933
quote:
0s.gif Op donderdag 5 januari 2012 22:31 schreef Pakspul het volgende:

[..]

Of je verdiept je een keer in classes en bent ook per direct van het gezeik af. Dan ben je nog flexibeler :)
Klopt, daar ben ik ook zeer grote voorstander van (als onderdeel van MVC- en OOP-programmeren).
  donderdag 5 januari 2012 @ 23:41:46 #192
159156 Dokay
Ago ergo sum
pi_106464898
Bedankt voor jullie reacties! Ik ga morgen eens kijken of ik verder kom. :)
  vrijdag 6 januari 2012 @ 00:44:42 #194
75592 GlowMouse
l'état, c'est moi
pi_106467510
Er zijn teveel amateurs :Y
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
  vrijdag 6 januari 2012 @ 00:50:03 #195
111382 Ofyles2
Bestemming: onbekend
pi_106467720
quote:
0s.gif Op vrijdag 6 januari 2012 00:44 schreef GlowMouse het volgende:
Er zijn teveel amateurs :Y
It wasn't me...
pi_106467852
quote:
0s.gif Op vrijdag 6 januari 2012 00:44 schreef GlowMouse het volgende:
Er zijn teveel amateurs :Y
*meldt.

Daarom ga ik ook niet datsoort systemen klussen, Maar srsly, een maximale lengte aan het password veld geven om SQL injectie te voorkomen? Echt wtf! Blijkbaar heeft iemand er wel over nagedacht dus, maar toen besloten dat mysql_real_escape() te moeilijk was ofzo :') Nog even los van de vragen over hoe dat in hemelsnaam gehashed is als die input zo de query in geslingerd wordt...
  vrijdag 6 januari 2012 @ 00:55:16 #197
75592 GlowMouse
l'état, c'est moi
pi_106467883
quote:
14s.gif Op vrijdag 6 januari 2012 00:54 schreef KomtTijd... het volgende:

[..]

Maar srsly, een maximale lengte aan het password veld geven om SQL injectie te voorkomen?
Die reden zal wel later bedacht zijn. Als hashing ontbreekt zal de lengte van het db-veld de ware reden achter de beperking tot 12 karakters zijn.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
  vrijdag 6 januari 2012 @ 00:57:33 #198
111382 Ofyles2
Bestemming: onbekend
pi_106467961
quote:
14s.gif Op vrijdag 6 januari 2012 00:54 schreef KomtTijd... het volgende:

[..]

*meldt.

Daarom ga ik ook niet datsoort systemen klussen, Maar srsly, een maximale lengte aan het password veld geven om SQL injectie te voorkomen? Echt wtf! Blijkbaar heeft iemand er wel over nagedacht dus, maar toen besloten dat mysql_real_escape() te moeilijk was ofzo :') Nog even los van de vragen over hoe dat in hemelsnaam gehashed is als die input zo de query in geslingerd wordt...
Zoiets hoor je eerder op te lossen met preg_match en PDO.
pi_106468034
quote:
0s.gif Op vrijdag 6 januari 2012 00:57 schreef Ofyles2 het volgende:

[..]

Zoiets hoor je eerder op te lossen met preg_match en PDO.
Preg_match :? En ja tegenwoordig doet iedereen dat met PDO of MySQLi (of aanverwanten in andere talen) maar als die website 5 jaar oud is ga je 'm niet helemaal herschrijven daarvoor.
  vrijdag 6 januari 2012 @ 01:03:07 #200
111382 Ofyles2
Bestemming: onbekend
pi_106468162
quote:
5s.gif Op vrijdag 6 januari 2012 00:59 schreef KomtTijd... het volgende:

[..]

Preg_match :? En ja tegenwoordig doet iedereen dat met PDO of MySQLi (of aanverwanten in andere talen) maar als die website 5 jaar oud is ga je 'm niet helemaal herschrijven daarvoor.
Preg_match voor reguliere expressies. Je kunt nooit 100% zeker zijn dat al je bezoekers zo poeslief zijn...
abonnement bol.com Unibet Coolblue
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')