<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:dc="http://purl.org/dc/elements/1.1/"
 xmlns:content="http://purl.org/rss/1.0/modules/content/"
 xmlns:atom="http://www.w3.org/2005/Atom"
>
	<channel>
		<copyright>Copyright 1998 - 2026 DPG Media B.V.</copyright>
		<pubDate>Tue, 10 Nov 2026 20:43:21 GMT</pubDate>
		<lastBuildDate>Tue, 10 Nov 2026 20:43:21 GMT</lastBuildDate>
		<description>GoT - list_messages</description>
		<image>
			<link>https://gathering.tweakers.net/</link>
			<title>Gathering of Tweakers</title>
			<url>https://tweakers.net/icon-192.png</url>
		</image>
		<language>nl-nl</language>
		<link>https://gathering.tweakers.net/rss/list_messages/1419686</link>
		<atom:link href="https://gathering.tweakers.net/rss/list_messages/1419686" rel="self" type="application/rss+xml" />
		<title>[PHP] Beveiling (POST) - Softwareontwikkeling - GoT</title>
		<webMaster>gathering@tweakers.net (Administrator)</webMaster>
		<item>
			<title>Niemand_Anders</title>
			<link>https://gathering.tweakers.net/forum/list_message/34457962#34457962</link>
			<description>Guillome schreef op maandag 02 augustus 2010 @ 09:22:
Waar baseer je dat nou op?
Een deelnemer met onjuiste rechten krijgt idd danwel de inlog pagina, danwel de foutmelding dat hij niet genoeg rechten heeft.
Maar een gebruiker met voldoende rechten kan via zijn eigen form acties uitvoeren die eigenlijk alleen via de site mogen gaan. Het baart me zorgen dat dat vanaf eigen formulieren kan gaan. Daar gaat mijn vraag over:
Hoe weet ik zeker dat een post-request door mijn site is gedaan.
Ik ga nu de aangeboden oplossingen doornemenJe weet dat HTTP stateless is toch? Technisch gezien bestaat er niet zoals als een post vanaf je eigen website. Een HTML formulier is niet anders dan een collectie van key/value waardes welke in de volgende request worden meegegeven. Je zou een random id kunnen genereren en dit id in zowel de sessie als formulier plaatsen. Bij de post kun je controleren of deze id&#039;s nog steeds kloppen en anders 400 status code (bad request) terug geven.

En als je bang bent dat iemand offline je formulier aanpast. Via browser extensies zoals greasemonkey zijn ook online formulieren te wijzigen bij jouw controle om. in het kort: Jij hebt geen controle of wat er gebeurt tussen het moment dat jij het formulier naar de browser stuurt en later weer terug komt. HTTP referer checks werken in de regel niet omdat veel security producten (zoals een anti-virus scanner zoals Norton Security) standaard de referer leegmaken uit privacy oogpunt.

Daarnaast als je een goede serversided validatie hebt om de inkomende velden, dan maakt het eigenlijk niet of iemand het formulier wel of niet wijzigd. Wat betreft het overnemen van sessies. Veel sessie providers bieden de mogelijkheid om sessies aan een IP te koppelen. Dit maakt het een erg stuk lastiger om sessies over te nemen, maar niet onmogelijk. 

Tegenwoordig komt het overgrote deel van de hack pogingen vooral van scriptkiddies welke niets of weinig van de materie afweten. De hackers/crackers met voldoende kennis en mogelijkheden om man in the middle attacks te creëren zijn vooral geïnteresseerd in grote websites.

Als je frameworks zoals Joomla of WordPress is het vooral zaak om te zorgen dat je snel de updates installeert en vooral oplet met extensies voor dergelijke platformen. Veel van deze extensies zijn geschreven door beginnende programmeurs en zitten helaas vaak vol met exploits..</description>
			<content:encoded><![CDATA[<blockquote><div class="message-quote-div"><b><a href="https://gathering.tweakers.net/forum/list_message/34449806#34449806" rel="external" class="messagelink">Guillome schreef op maandag 02 augustus 2010 @ 09:22</a>:</b><br>
Waar baseer je dat nou op?<br>
Een deelnemer met onjuiste rechten krijgt idd danwel de inlog pagina, danwel de foutmelding dat hij niet genoeg rechten heeft.<br>
Maar een gebruiker met voldoende rechten kan via zijn eigen form acties uitvoeren die eigenlijk alleen via de site mogen gaan. Het baart me zorgen dat dat vanaf eigen formulieren kan gaan. Daar gaat mijn vraag over:<br>
Hoe weet ik zeker dat een post-request door mijn site is gedaan.<br>
Ik ga nu de aangeboden oplossingen doornemen</div></blockquote>Je weet dat HTTP stateless is toch? Technisch gezien bestaat er niet zoals als een post vanaf je eigen website. Een HTML formulier is niet anders dan een collectie van key/value waardes welke in de volgende request worden meegegeven. Je zou een random id kunnen genereren en dit id in zowel de sessie als formulier plaatsen. Bij de post kun je controleren of deze id&#039;s nog steeds kloppen en anders 400 status code (bad request) terug geven.<br>
<br>
En als je bang bent dat iemand offline je formulier aanpast. Via browser extensies zoals greasemonkey zijn ook online formulieren te wijzigen bij jouw controle om. in het kort: Jij hebt geen controle of wat er gebeurt tussen het moment dat jij het formulier naar de browser stuurt en later weer terug komt. HTTP referer checks werken in de regel niet omdat veel security producten (zoals een anti-virus scanner zoals Norton Security) standaard de referer leegmaken uit privacy oogpunt.<br>
<br>
Daarnaast als je een goede serversided validatie hebt om de inkomende velden, dan maakt het eigenlijk niet of iemand het formulier wel of niet wijzigd. Wat betreft het overnemen van sessies. Veel sessie providers bieden de mogelijkheid om sessies aan een IP te koppelen. Dit maakt het een erg stuk lastiger om sessies over te nemen, maar niet onmogelijk. <br>
<br>
Tegenwoordig komt het overgrote deel van de hack pogingen vooral van scriptkiddies welke niets of weinig van de materie afweten. De hackers/crackers met voldoende kennis en mogelijkheden om man in the middle attacks te creëren zijn vooral geïnteresseerd in grote websites.<br>
<br>
Als je frameworks zoals Joomla of WordPress is het vooral zaak om te zorgen dat je snel de updates installeert en vooral oplet met extensies voor dergelijke platformen. Veel van deze extensies zijn geschreven door beginnende programmeurs en zitten helaas vaak vol met exploits..]]></content:encoded>
			<dc:creator>Niemand_Anders</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34457962#34457962</guid>
			<pubDate>Tue, 03 Aug 2010 12:31:52 GMT</pubDate>
		</item>
		<item>
			<title>Janoz</title>
			<link>https://gathering.tweakers.net/forum/list_message/34449853#34449853</link>
			<description>Remus schreef op maandag 02 augustus 2010 @ 09:10:
[...]


Waarschijnlijk regelt de TS zijn beveiliging aan de clientside (door wel of niet bepaalde zaken in de HTML op te nemen), ipv aan serverside te controleren of de gebruiker wel de benodigde rechten heeft om een bepaalde actie uit te voeren.Nope. Topicstarter is bezig met zich te wapenen tegen CSRF. Iemand die wel de rechten heeft en ingelogd is naar een pagina lokken waarop je middels javascript verschillende POST request op de site afvuurt. Hierdoor kun je acties uithalen met het slachtoffer zijn rechtenset.</description>
			<content:encoded><![CDATA[<blockquote><div class="message-quote-div"><b><a href="https://gathering.tweakers.net/forum/list_message/34449752#34449752" rel="external" class="messagelink">Remus schreef op maandag 02 augustus 2010 @ 09:10</a>:</b><br>
[...]<br>
<br>
<br>
Waarschijnlijk regelt de TS zijn beveiliging aan de clientside (door wel of niet bepaalde zaken in de HTML op te nemen), ipv aan serverside te controleren of de gebruiker wel de benodigde rechten heeft om een bepaalde actie uit te voeren.</div></blockquote>Nope. Topicstarter is bezig met zich te wapenen tegen CSRF. Iemand die wel de rechten heeft en ingelogd is naar een pagina lokken waarop je middels javascript verschillende POST request op de site afvuurt. Hierdoor kun je acties uithalen met het slachtoffer zijn rechtenset.]]></content:encoded>
			<dc:creator>Janoz</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34449853#34449853</guid>
			<pubDate>Mon, 02 Aug 2010 07:31:22 GMT</pubDate>
		</item>
		<item>
			<title>Guillome</title>
			<link>https://gathering.tweakers.net/forum/list_message/34449806#34449806</link>
			<description>Waar baseer je dat nou op?
Een deelnemer met onjuiste rechten krijgt idd danwel de inlog pagina, danwel de foutmelding dat hij niet genoeg rechten heeft.
Maar een gebruiker met voldoende rechten kan via zijn eigen form acties uitvoeren die eigenlijk alleen via de site mogen gaan. Het baart me zorgen dat dat vanaf eigen formulieren kan gaan. Daar gaat mijn vraag over:
Hoe weet ik zeker dat een post-request door mijn site is gedaan.
Ik ga nu de aangeboden oplossingen doornemen</description>
			<content:encoded><![CDATA[Waar baseer je dat nou op?<br>
Een deelnemer met onjuiste rechten krijgt idd danwel de inlog pagina, danwel de foutmelding dat hij niet genoeg rechten heeft.<br>
Maar een gebruiker met voldoende rechten kan via zijn eigen form acties uitvoeren die eigenlijk alleen via de site mogen gaan. Het baart me zorgen dat dat vanaf eigen formulieren kan gaan. Daar gaat mijn vraag over:<br>
Hoe weet ik zeker dat een post-request door mijn site is gedaan.<br>
Ik ga nu de aangeboden oplossingen doornemen]]></content:encoded>
			<dc:creator>Guillome</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34449806#34449806</guid>
			<pubDate>Mon, 02 Aug 2010 07:22:35 GMT</pubDate>
		</item>
		<item>
			<title>Remus</title>
			<link>https://gathering.tweakers.net/forum/list_message/34449752#34449752</link>
			<description>Cartman! schreef op zondag 01 augustus 2010 @ 20:04:
Na meerdere keren het topic lezen mis ik nog steeds t probleem. Stel dat iemand die url heeft, zodra hij het op een of andere manier oproept (via browser danwel script) dan krijgt ie toch gewoon een keurige pagina te zien waarop staat dat ie gee rechten heeft?Waarschijnlijk regelt de TS zijn beveiliging aan de clientside (door wel of niet bepaalde zaken in de HTML op te nemen), ipv aan serverside te controleren of de gebruiker wel de benodigde rechten heeft om een bepaalde actie uit te voeren.</description>
			<content:encoded><![CDATA[<blockquote><div class="message-quote-div"><b><a href="https://gathering.tweakers.net/forum/list_message/34448020#34448020" rel="external" class="messagelink">Cartman! schreef op zondag 01 augustus 2010 @ 20:04</a>:</b><br>
Na meerdere keren het topic lezen mis ik nog steeds t probleem. Stel dat iemand die url heeft, zodra hij het op een of andere manier oproept (via browser danwel script) dan krijgt ie toch gewoon een keurige pagina te zien waarop staat dat ie gee rechten heeft?</div></blockquote>Waarschijnlijk regelt de TS zijn beveiliging aan de clientside (door wel of niet bepaalde zaken in de HTML op te nemen), ipv aan serverside te controleren of de gebruiker wel de benodigde rechten heeft om een bepaalde actie uit te voeren.]]></content:encoded>
			<dc:creator>Remus</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34449752#34449752</guid>
			<pubDate>Mon, 02 Aug 2010 07:10:11 GMT</pubDate>
		</item>
		<item>
			<title>Kalentum</title>
			<link>https://gathering.tweakers.net/forum/list_message/34448153#34448153</link>
			<description>Cartman! schreef op zondag 01 augustus 2010 @ 20:04:
Overigens staan mijn rechten in de database, niet in de sessie zelf. Sterker nog, ik gebruik geen sessies maar gewoon een cookie met een ID erin die matcht met een user via mijn session-tabel. Bij het inloggen staat het locken op IP automatisch al aan dus kopieren van het ID zal meestal niet lukken. Eventueel kun je nog checken op useragent.Wat is het grote verschil tussen PHP&#039;s sessie-implementatie en je eigen? En hoe hou je state bij? alles in de database?</description>
			<content:encoded><![CDATA[<blockquote><div class="message-quote-div"><b><a href="https://gathering.tweakers.net/forum/list_message/34448020#34448020" rel="external" class="messagelink">Cartman! schreef op zondag 01 augustus 2010 @ 20:04</a>:</b><br>
Overigens staan mijn rechten in de database, niet in de sessie zelf. Sterker nog, ik gebruik geen sessies maar gewoon een cookie met een ID erin die matcht met een user via mijn session-tabel. Bij het inloggen staat het locken op IP automatisch al aan dus kopieren van het ID zal meestal niet lukken. Eventueel kun je nog checken op useragent.</div></blockquote>Wat is het grote verschil tussen PHP&#039;s sessie-implementatie en je eigen? En hoe hou je state bij? alles in de database?]]></content:encoded>
			<dc:creator>Kalentum</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34448153#34448153</guid>
			<pubDate>Sun, 01 Aug 2010 18:33:00 GMT</pubDate>
		</item>
		<item>
			<title>Cartman!</title>
			<link>https://gathering.tweakers.net/forum/list_message/34448020#34448020</link>
			<description>Na meerdere keren het topic lezen mis ik nog steeds t probleem. Stel dat iemand die url heeft, zodra hij het op een of andere manier oproept (via browser danwel script) dan krijgt ie toch gewoon een keurige pagina te zien waarop staat dat ie gee rechten heeft?

Overigens staan mijn rechten in de database, niet in de sessie zelf. Sterker nog, ik gebruik geen sessies maar gewoon een cookie met een ID erin die matcht met een user via mijn session-tabel. Bij het inloggen staat het locken op IP automatisch al aan dus kopieren van het ID zal meestal niet lukken. Eventueel kun je nog checken op useragent.

Dat icm. crisp zijn oplossing voor CSRF lijkt het me vrij waterdicht.</description>
			<content:encoded><![CDATA[Na meerdere keren het topic lezen mis ik nog steeds t probleem. Stel dat iemand die url heeft, zodra hij het op een of andere manier oproept (via browser danwel script) dan krijgt ie toch gewoon een keurige pagina te zien waarop staat dat ie gee rechten heeft?<br>
<br>
Overigens staan mijn rechten in de database, niet in de sessie zelf. Sterker nog, ik gebruik geen sessies maar gewoon een cookie met een ID erin die matcht met een user via mijn session-tabel. Bij het inloggen staat het locken op IP automatisch al aan dus kopieren van het ID zal meestal niet lukken. Eventueel kun je nog checken op useragent.<br>
<br>
Dat icm. crisp zijn oplossing voor CSRF lijkt het me vrij waterdicht.]]></content:encoded>
			<dc:creator>Cartman!</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34448020#34448020</guid>
			<pubDate>Sun, 01 Aug 2010 18:04:01 GMT</pubDate>
		</item>
		<item>
			<title>Guillome</title>
			<link>https://gathering.tweakers.net/forum/list_message/34447992#34447992</link>
			<description>Hoe bedoel je? Rechten staan al in de sessie, maar hoezo meeposten?</description>
			<content:encoded><![CDATA[Hoe bedoel je? Rechten staan al in de sessie, maar hoezo meeposten?]]></content:encoded>
			<dc:creator>Guillome</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34447992#34447992</guid>
			<pubDate>Sun, 01 Aug 2010 17:56:34 GMT</pubDate>
		</item>
		<item>
			<title>kevinkrs</title>
			<link>https://gathering.tweakers.net/forum/list_message/34447377#34447377</link>
			<description>Als je de rechten nu in een sessie opslaat, en die mee post ben je er toch?</description>
			<content:encoded><![CDATA[Als je de rechten nu in een sessie opslaat, en die mee post ben je er toch?]]></content:encoded>
			<dc:creator>kevinkrs</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34447377#34447377</guid>
			<pubDate>Sun, 01 Aug 2010 15:35:36 GMT</pubDate>
		</item>
		<item>
			<title>Guillome</title>
			<link>https://gathering.tweakers.net/forum/list_message/34446481#34446481</link>
			<description>Wat ik hier onder een hack versta is wanneer een gebruiker zonder rechten zichzelf of een ander een beoordeling kan geven</description>
			<content:encoded><![CDATA[Wat ik hier onder een hack versta is wanneer een gebruiker zonder rechten zichzelf of een ander een beoordeling kan geven]]></content:encoded>
			<dc:creator>Guillome</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34446481#34446481</guid>
			<pubDate>Sun, 01 Aug 2010 12:54:23 GMT</pubDate>
		</item>
		<item>
			<title>Feanathiel</title>
			<link>https://gathering.tweakers.net/forum/list_message/34446449#34446449</link>
			<description>Voutloos schreef op zondag 01 augustus 2010 @ 11:31:
Deze 2 soorten aanvallen staan helemaal los van elkaar.Daarom, het is maar net wat je onder een hack verstaat. Is het iemand extern of is het de persoon zelf? Er zijn meerdere soorten aanvallen waar je jouw website tegen zult moeten beschermen.

De MitM-attack kan trouwens ook worden doorgetrokken in de richting van de XSS (cross site scripting), waarbij de gegevens gewoonweg met behulp van AJAX wordt verstuurd naar een ongewenst persoon.</description>
			<content:encoded><![CDATA[<blockquote><div class="message-quote-div"><b><a href="https://gathering.tweakers.net/forum/list_message/34445488#34445488" rel="external" class="messagelink">Voutloos schreef op zondag 01 augustus 2010 @ 11:31</a>:</b><br>
Deze 2 soorten aanvallen staan helemaal los van elkaar.</div></blockquote>Daarom, het is maar net wat je onder een hack verstaat. Is het iemand extern of is het de persoon zelf? Er zijn meerdere soorten aanvallen waar je jouw website tegen zult moeten beschermen.<br>
<br>
De MitM-attack kan trouwens ook worden doorgetrokken in de richting van de XSS (cross site scripting), waarbij de gegevens gewoonweg met behulp van AJAX wordt verstuurd naar een ongewenst persoon.]]></content:encoded>
			<dc:creator>Feanathiel</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34446449#34446449</guid>
			<pubDate>Sun, 01 Aug 2010 12:51:05 GMT</pubDate>
		</item>
		<item>
			<title>Voutloos</title>
			<link>https://gathering.tweakers.net/forum/list_message/34445488#34445488</link>
			<description>Feanathiel heeft het vooral over Man-in-the-Middle attacks, terwijl de rest het vooral over csrf heeft. Er worden hier goede oplossingen tegen csrf aangereikt, maar daarin zit niets dat voorkomt dat een authentieke request door een tussenschakel gewijzigd wordt. Voor bescherming tegen mitm heb je https (inc. certificate checks) nodig.

Deze 2 soorten aanvallen staan helemaal los van elkaar.</description>
			<content:encoded><![CDATA[Feanathiel heeft het vooral over Man-in-the-Middle attacks, terwijl de rest het vooral over csrf heeft. Er worden hier goede oplossingen tegen csrf aangereikt, maar daarin zit niets dat voorkomt dat een authentieke request door een tussenschakel gewijzigd wordt. Voor bescherming tegen mitm heb je https (inc. certificate checks) nodig.<br>
<br>
Deze 2 soorten aanvallen staan helemaal los van elkaar.]]></content:encoded>
			<dc:creator>Voutloos</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34445488#34445488</guid>
			<pubDate>Sun, 01 Aug 2010 09:31:52 GMT</pubDate>
		</item>
		<item>
			<title>Guillome</title>
			<link>https://gathering.tweakers.net/forum/list_message/34445442#34445442</link>
			<description>Feanathiel schreef op zaterdag 31 juli 2010 @ 20:32:
[...]
Als je op een of andere manier het sessienummer kunt uitlezen, wat zeker mogelijk is, dan is het ook niet lastig om de &#039;checksum&#039; uit te lezen. Deze wordt namelijk gewoonweg mee gestuurd als POST-parameter.Dit kan toch niet? Dat ik vanaf mijn PC thuis een eigen formulier maak en erin kan?

In het pakket ben ik ingelogd als gebruiker met random rechten (maakt even niet uit), dan heb ik toch een sessie toegewezen gekregen welke in de database staat. Bij het beoordeelformulier wordt het checksum aangemaakt en in de DB gezet.

Als ik mijn eigen formuliertje wil verzenden weet ik toch niet welke checksum ik gebruiken moet? Als je de &#039;echte&#039; pagina erbij pakt, kan je de checksum zien staan ja, maar dan nog klopt het sessie ID niet van de postrequest je eigen formuliertje.

Ik vind het lastig om te doorzien hoe je dit zou kunnen hacken. Ik ga de 2 genoemde links vandaag doorlezen

Edit:
Ik zie dat de referer idd zomaar gefaked kan worden, die optie valt dus af.
Edit2: al klopt de sessie_ID dan niet meer.....</description>
			<content:encoded><![CDATA[<blockquote><div class="message-quote-div"><b><a href="https://gathering.tweakers.net/forum/list_message/34443940#34443940" rel="external" class="messagelink">Feanathiel schreef op zaterdag 31 juli 2010 @ 20:32</a>:</b><br>
[...]<br>
Als je op een of andere manier het sessienummer kunt uitlezen, wat zeker mogelijk is, dan is het ook niet lastig om de &#039;checksum&#039; uit te lezen. Deze wordt namelijk gewoonweg mee gestuurd als POST-parameter.</div></blockquote>Dit kan toch niet? Dat ik vanaf mijn PC thuis een eigen formulier maak en erin kan?<br>
<br>
In het pakket ben ik ingelogd als gebruiker met random rechten (maakt even niet uit), dan heb ik toch een sessie toegewezen gekregen welke in de database staat. Bij het beoordeelformulier wordt het checksum aangemaakt en in de DB gezet.<br>
<br>
Als ik mijn eigen formuliertje wil verzenden weet ik toch niet welke checksum ik gebruiken moet? Als je de &#039;echte&#039; pagina erbij pakt, kan je de checksum zien staan ja, maar dan nog klopt het sessie ID niet van de postrequest je eigen formuliertje.<br>
<br>
Ik vind het lastig om te doorzien hoe je dit zou kunnen hacken. Ik ga de 2 genoemde links vandaag doorlezen<br>
<br>
Edit:<br>
Ik zie dat de referer idd zomaar gefaked kan worden, die optie valt dus af.<br>
Edit2: al klopt de sessie_ID dan niet meer.....]]></content:encoded>
			<dc:creator>Guillome</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34445442#34445442</guid>
			<pubDate>Sun, 01 Aug 2010 09:21:09 GMT</pubDate>
		</item>
		<item>
			<title>Kalentum</title>
			<link>https://gathering.tweakers.net/forum/list_message/34444508#34444508</link>
			<description>Verwijderd schreef op zaterdag 31 juli 2010 @ 20:49:
@Guillome:

Zowel POST als COOKIE zijn 100% afhankelijk van de input van de client. Die controle is dus redelijk zinloos.

Ook de referer is onder de invloed van de client, het is de client die dit meestuurt en heeft dus niets met de server te maken. Daarnaast maak je het voor jezelf heel moelijk doordat je overal precies moet weten waar de gebruiker allemaal mogelijk vandaan moet komen. Een onderhoud nachtmerrie!

Helaas biedt je op deze manier dus geen goede beveiliging, je maakt het alleen zeer omslachtig waardoor het veiliger lijkt, maar feitelijk is dat het niet.Hij wil die cookies helemaal niet gebruiken, zie het commentaar in de code. Blijkbaar zullen die die in de database worden opgeslagen.</description>
			<content:encoded><![CDATA[<blockquote><div class="message-quote-div"><b><a href="https://gathering.tweakers.net/forum/list_message/34444013#34444013" rel="external" class="messagelink">Verwijderd schreef op zaterdag 31 juli 2010 @ 20:49</a>:</b><br>
@Guillome:<br>
<br>
Zowel POST als COOKIE zijn 100% afhankelijk van de input van de client. Die controle is dus redelijk zinloos.<br>
<br>
Ook de referer is onder de invloed van de client, het is de client die dit meestuurt en heeft dus niets met de server te maken. Daarnaast maak je het voor jezelf heel moelijk doordat je overal precies moet weten waar de gebruiker allemaal mogelijk vandaan moet komen. Een onderhoud nachtmerrie!<br>
<br>
Helaas biedt je op deze manier dus geen goede beveiliging, je maakt het alleen zeer omslachtig waardoor het veiliger lijkt, maar feitelijk is dat het niet.</div></blockquote>Hij wil die cookies helemaal niet gebruiken, zie het commentaar in de code. Blijkbaar zullen die die in de database worden opgeslagen.]]></content:encoded>
			<dc:creator>Kalentum</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34444508#34444508</guid>
			<pubDate>Sat, 31 Jul 2010 20:59:36 GMT</pubDate>
		</item>
		<item>
			<title>crisp</title>
			<link>https://gathering.tweakers.net/forum/list_message/34444033#34444033</link>
			<description>rutgerw schreef op zaterdag 31 juli 2010 @ 17:12:
[...]
Een andere mogelijkheid is om elk HTML formulier een unieke random hash mee te geven in een hidden field. Die unieke hash plaats je ook in de sessie en laat je verlopen na een bepaalde tijd. Als je een formulier binnenkrijgt van de gebruiker en de unieke hash klopt niet met wat je in de sessie hebt staan, weet je dat het formulier vanaf een andere bron komt.
Zie bv http://www.codinghorror.c...srf-and-xsrf-attacks.html voor meer info.Laatst nog een blogpost geschreven hoe wij gebruik maken van tokens hier op Tweakers.net: Crisp&#039;s blog: CSRF protection with &#039;self-validating&#039; tokens</description>
			<content:encoded><![CDATA[<blockquote><div class="message-quote-div"><b><a href="https://gathering.tweakers.net/forum/list_message/34443175#34443175" rel="external" class="messagelink">rutgerw schreef op zaterdag 31 juli 2010 @ 17:12</a>:</b><br>
[...]<br>
Een andere mogelijkheid is om elk HTML formulier een unieke random hash mee te geven in een hidden field. Die unieke hash plaats je ook in de sessie en laat je verlopen na een bepaalde tijd. Als je een formulier binnenkrijgt van de gebruiker en de unieke hash klopt niet met wat je in de sessie hebt staan, weet je dat het formulier vanaf een andere bron komt.<br>
Zie bv <a href="http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html" rel="external nofollow" title="http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html">http://www.codinghorror.c...srf-and-xsrf-attacks.html</a> voor meer info.</div></blockquote>Laatst nog een blogpost geschreven hoe wij gebruik maken van tokens hier op Tweakers.net: <a href="http://crisp.tweakblogs.net/blog/3928/csrf-protection-with-self-validating-tokens.html" rel="external nofollow">Crisp&#039;s blog: CSRF protection with &#039;self-validating&#039; tokens</a>]]></content:encoded>
			<dc:creator>crisp</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34444033#34444033</guid>
			<pubDate>Sat, 31 Jul 2010 18:52:11 GMT</pubDate>
		</item>
		<item>
			<title>Verwijderd</title>
			<link>https://gathering.tweakers.net/forum/list_message/34444013#34444013</link>
			<description>@Guillome:

Zowel POST als COOKIE zijn 100% afhankelijk van de input van de client. Die controle is dus redelijk zinloos.

Ook de referer is onder de invloed van de client, het is de client die dit meestuurt en heeft dus niets met de server te maken. Daarnaast maak je het voor jezelf heel moelijk doordat je overal precies moet weten waar de gebruiker allemaal mogelijk vandaan moet komen. Een onderhoud nachtmerrie!

Helaas biedt je op deze manier dus geen goede beveiliging, je maakt het alleen zeer omslachtig waardoor het veiliger lijkt, maar feitelijk is dat het niet.</description>
			<content:encoded><![CDATA[@Guillome:<br>
<br>
Zowel POST als COOKIE zijn 100% afhankelijk van de input van de client. Die controle is dus redelijk zinloos.<br>
<br>
Ook de referer is onder de invloed van de client, het is de client die dit meestuurt en heeft dus niets met de server te maken. Daarnaast maak je het voor jezelf heel moelijk doordat je overal precies moet weten waar de gebruiker allemaal mogelijk vandaan moet komen. Een onderhoud nachtmerrie!<br>
<br>
Helaas biedt je op deze manier dus geen goede beveiliging, je maakt het alleen zeer omslachtig waardoor het veiliger lijkt, maar feitelijk is dat het niet.]]></content:encoded>
			<dc:creator>Verwijderd</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34444013#34444013</guid>
			<pubDate>Sat, 31 Jul 2010 18:49:34 GMT</pubDate>
		</item>
		<item>
			<title>Feanathiel</title>
			<link>https://gathering.tweakers.net/forum/list_message/34443940#34443940</link>
			<description>Guillome schreef op zaterdag 31 juli 2010 @ 16:12:
Ten tweede: zijn SESSIONS te hacken? Daar in staat of, en hoe je ingelogd bent met welke rechten. Nu wordt er in die scripts opnieuw de inlog gecontroleerd, maar hij haalt dat toch echt uit de sessies.Het ligt er maar net aan wat je onder hacken verstaat. De inhoud van een sessie is niet uit te lezen vanuit de client, tenzij je dat specifiek in een PHP script zet. Sessions zijn echter wel over te nemen. Stel dat jij op een website terrecht komt en daar een sessionnummer aangewezen krijgt, dan kan ik dit nummer overnemen en verder browsen onder jouw naam. Dit kan alleen als er geen maatregelen getroffen zijn.

Als je op een of andere manier het sessienummer kunt uitlezen, wat zeker mogelijk is, dan is het ook niet lastig om de &#039;checksum&#039; uit te lezen. Deze wordt namelijk gewoonweg mee gestuurd als POST-parameter. Door slechts één (netwerk-)pakket uit te lezen, zou je toegang kunnen verkrijgen vanaf een pc van buiten af. In principe houdt je alleen de beginnende &#039;hacker&#039; hier mee weg. Een beter alternatief zou zijn, om bijvoorbeeld op IP te gaan controleren, maar let hierbij ook op de nadelen hiervan. In ieder geval een gegeven dat niet door de gebruiker aangepast kan worden. Uiteraard helpt het HTTPS-protocol hier ook bij. Alleen een man-in-the-middle attack zou hierbij nog zin hebben (of je zou goed moeten kunnen gokken wat de combinatie van de checksum en het sessienummer is).</description>
			<content:encoded><![CDATA[<blockquote><div class="message-quote-div"><b><a href="https://gathering.tweakers.net/forum/list_message/34442900#34442900" rel="external" class="messagelink">Guillome schreef op zaterdag 31 juli 2010 @ 16:12</a>:</b><br>
Ten tweede: zijn SESSIONS te hacken? Daar in staat of, en hoe je ingelogd bent met welke rechten. Nu wordt er in die scripts opnieuw de inlog gecontroleerd, maar hij haalt dat toch echt uit de sessies.</div></blockquote>Het ligt er maar net aan wat je onder hacken verstaat. De inhoud van een sessie is niet uit te lezen vanuit de client, tenzij je dat specifiek in een PHP script zet. Sessions zijn echter wel over te nemen. Stel dat jij op een website terrecht komt en daar een sessionnummer aangewezen krijgt, dan kan ik dit nummer overnemen en verder browsen onder jouw naam. Dit kan alleen als er geen maatregelen getroffen zijn.<br>
<br>
Als je op een of andere manier het sessienummer kunt uitlezen, wat zeker mogelijk is, dan is het ook niet lastig om de &#039;checksum&#039; uit te lezen. Deze wordt namelijk gewoonweg mee gestuurd als POST-parameter. Door slechts één (netwerk-)pakket uit te lezen, zou je toegang kunnen verkrijgen vanaf een pc van buiten af. In principe houdt je alleen de beginnende &#039;hacker&#039; hier mee weg. Een beter alternatief zou zijn, om bijvoorbeeld op IP te gaan controleren, maar let hierbij ook op de nadelen hiervan. In ieder geval een gegeven dat niet door de gebruiker aangepast kan worden. Uiteraard helpt het HTTPS-protocol hier ook bij. Alleen een man-in-the-middle attack zou hierbij nog zin hebben (of je zou goed moeten kunnen gokken wat de combinatie van de checksum en het sessienummer is).]]></content:encoded>
			<dc:creator>Feanathiel</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34443940#34443940</guid>
			<pubDate>Sat, 31 Jul 2010 18:32:44 GMT</pubDate>
		</item>
		<item>
			<title>Guillome</title>
			<link>https://gathering.tweakers.net/forum/list_message/34443707#34443707</link>
			<description>Ok dus dit zou veilig moeten zijn (nu nog met cookies, dat gaat straks een DB in, functie  rand_str is als voorbeeld)

Formulier:
PHP:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
&lt;?php
  session_start();
  session_regenerate_id(); // na en enkel na het active inloggen
  setcookie(&quot;sid&quot;, session_id(), time()+3600); // gaat de database in: na en enkel na het active inloggen
  setcookie(&quot;check&quot;, ($check=rand_str()), time()+3600); // gaat ook de database in, in het session record
  
  function rand_str()
  {
    $s = &quot;&quot;;
    for($x=0;$x&lt;10;$x++)
      $s .= chr(rand(ord(&quot;a&quot;), ord(&quot;z&quot;)));
    return $s;
  }
?&gt;
&lt;form method=&quot;post&quot; action=&quot;hack2.php&quot;&gt;
  &lt;input name=&quot;user_ID&quot; value=&quot;251&quot; /&gt;
  &lt;input name=&quot;ID&quot; value=&quot;21&quot; /&gt;
  &lt;input name=&quot;beoordeling&quot; value=&quot;2&quot; /&gt;
  &lt;input name=&quot;check&quot; value=&quot;&lt;?=$check;?&gt;&quot; /&gt;
  &lt;input type=&quot;submit&quot; /&gt;
&lt;/form&gt;

En de ontvanger:
PHP:1
2
3
4
5
6
7
8
9
&lt;?php
  session_start();
  $h = getallheaders();
  $r = $h[&quot;Referer&quot;];
  $d = $_SERVER[&quot;HTTP_HOST&quot;];
  if (session_id() != $_COOKIE[&quot;sid&quot;]) die(&quot;Foute sessie&quot;); // haal uit DB, niet uit cookie
  if (!in_array($r, Array(&quot;http://$d/hack.php&quot;))) die(&quot;Foute referer&quot;);
  if ($_POST[&quot;check&quot;] != $_COOKIE[&quot;check&quot;]) die (&quot;Foute checksum&quot;); // haal uit db. niet uit cookie
?&gt;</description>
			<content:encoded><![CDATA[Ok dus dit zou veilig moeten zijn (nu nog met cookies, dat gaat straks een DB in, functie  rand_str is als voorbeeld)<br>
<br>
Formulier:<br>
<div class="code">PHP:<br><table class="phphighlight"><tr><td class="phphighlightline"><pre>1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
</pre></td><td class="phphighlightcode"><div><pre><span class="code_cp">&lt;?php</span>
  <span class="code_nb">session_start</span><span class="code_p">();</span>
  <span class="code_nb">session_regenerate_id</span><span class="code_p">();</span> <span class="code_c1">// na en enkel na het active inloggen</span>
  <span class="code_nb">setcookie</span><span class="code_p">(</span><span class="code_s2">&quot;sid&quot;</span><span class="code_p">,</span> <span class="code_nb">session_id</span><span class="code_p">(),</span> <span class="code_nb">time</span><span class="code_p">()</span><span class="code_o">+</span><span class="code_mi">3600</span><span class="code_p">);</span> <span class="code_c1">// gaat de database in: na en enkel na het active inloggen</span>
  <span class="code_nb">setcookie</span><span class="code_p">(</span><span class="code_s2">&quot;check&quot;</span><span class="code_p">,</span> <span class="code_p">(</span><span class="code_nv">$check</span><span class="code_o">=</span><span class="code_nx">rand_str</span><span class="code_p">()),</span> <span class="code_nb">time</span><span class="code_p">()</span><span class="code_o">+</span><span class="code_mi">3600</span><span class="code_p">);</span> <span class="code_c1">// gaat ook de database in, in het session record</span>
  
  <span class="code_k">function</span> <span class="code_nf">rand_str</span><span class="code_p">()</span>
  <span class="code_p">{</span>
    <span class="code_nv">$s</span> <span class="code_o">=</span> <span class="code_s2">&quot;&quot;</span><span class="code_p">;</span>
    <span class="code_k">for</span><span class="code_p">(</span><span class="code_nv">$x</span><span class="code_o">=</span><span class="code_mi">0</span><span class="code_p">;</span><span class="code_nv">$x</span><span class="code_o">&lt;</span><span class="code_mi">10</span><span class="code_p">;</span><span class="code_nv">$x</span><span class="code_o">++</span><span class="code_p">)</span>
      <span class="code_nv">$s</span> <span class="code_o">.=</span> <span class="code_nb">chr</span><span class="code_p">(</span><span class="code_nb">rand</span><span class="code_p">(</span><span class="code_nb">ord</span><span class="code_p">(</span><span class="code_s2">&quot;a&quot;</span><span class="code_p">),</span> <span class="code_nb">ord</span><span class="code_p">(</span><span class="code_s2">&quot;z&quot;</span><span class="code_p">)));</span>
    <span class="code_k">return</span> <span class="code_nv">$s</span><span class="code_p">;</span>
  <span class="code_p">}</span>
<span class="code_cp">?&gt;</span>
<span class="code_x">&lt;form method=&quot;post&quot; action=&quot;hack2.php&quot;&gt;</span>
<span class="code_x">  &lt;input name=&quot;user_ID&quot; value=&quot;251&quot; /&gt;</span>
<span class="code_x">  &lt;input name=&quot;ID&quot; value=&quot;21&quot; /&gt;</span>
<span class="code_x">  &lt;input name=&quot;beoordeling&quot; value=&quot;2&quot; /&gt;</span>
<span class="code_x">  &lt;input name=&quot;check&quot; value=&quot;</span><span class="code_cp">&lt;?</span><span class="code_o">=</span><span class="code_nv">$check</span><span class="code_p">;</span><span class="code_cp">?&gt;</span><span class="code_x">&quot; /&gt;</span>
<span class="code_x">  &lt;input type=&quot;submit&quot; /&gt;</span>
<span class="code_x">&lt;/form&gt;</span></pre></div></td></tr></table></div><br>
<br>
En de ontvanger:<br>
<div class="code">PHP:<br><table class="phphighlight"><tr><td class="phphighlightline"><pre>1
2
3
4
5
6
7
8
9
</pre></td><td class="phphighlightcode"><div><pre><span class="code_cp">&lt;?php</span>
  <span class="code_nb">session_start</span><span class="code_p">();</span>
  <span class="code_nv">$h</span> <span class="code_o">=</span> <span class="code_nb">getallheaders</span><span class="code_p">();</span>
  <span class="code_nv">$r</span> <span class="code_o">=</span> <span class="code_nv">$h</span><span class="code_p">[</span><span class="code_s2">&quot;Referer&quot;</span><span class="code_p">];</span>
  <span class="code_nv">$d</span> <span class="code_o">=</span> <span class="code_nv">$_SERVER</span><span class="code_p">[</span><span class="code_s2">&quot;HTTP_HOST&quot;</span><span class="code_p">];</span>
  <span class="code_k">if</span> <span class="code_p">(</span><span class="code_nb">session_id</span><span class="code_p">()</span> <span class="code_o">!=</span> <span class="code_nv">$_COOKIE</span><span class="code_p">[</span><span class="code_s2">&quot;sid&quot;</span><span class="code_p">])</span> <span class="code_k">die</span><span class="code_p">(</span><span class="code_s2">&quot;Foute sessie&quot;</span><span class="code_p">);</span> <span class="code_c1">// haal uit DB, niet uit cookie</span>
  <span class="code_k">if</span> <span class="code_p">(</span><span class="code_o">!</span><span class="code_nb">in_array</span><span class="code_p">(</span><span class="code_nv">$r</span><span class="code_p">,</span> <span class="code_k">Array</span><span class="code_p">(</span><span class="code_s2">&quot;http://</span><span class="code_si">$d</span><span class="code_s2">/hack.php&quot;</span><span class="code_p">)))</span> <span class="code_k">die</span><span class="code_p">(</span><span class="code_s2">&quot;Foute referer&quot;</span><span class="code_p">);</span>
  <span class="code_k">if</span> <span class="code_p">(</span><span class="code_nv">$_POST</span><span class="code_p">[</span><span class="code_s2">&quot;check&quot;</span><span class="code_p">]</span> <span class="code_o">!=</span> <span class="code_nv">$_COOKIE</span><span class="code_p">[</span><span class="code_s2">&quot;check&quot;</span><span class="code_p">])</span> <span class="code_k">die</span> <span class="code_p">(</span><span class="code_s2">&quot;Foute checksum&quot;</span><span class="code_p">);</span> <span class="code_c1">// haal uit db. niet uit cookie</span>
<span class="code_cp">?&gt;</span></pre></div></td></tr></table></div>]]></content:encoded>
			<dc:creator>Guillome</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34443707#34443707</guid>
			<pubDate>Sat, 31 Jul 2010 17:35:17 GMT</pubDate>
		</item>
		<item>
			<title>Kalentum</title>
			<link>https://gathering.tweakers.net/forum/list_message/34443175#34443175</link>
			<description>In de eerste plaats moet je je autorisatie goed hebben. Als gebruiker X pogingen doet om iets te beoordelen wat niet mag, bv door de url te wijzigen, dan moet je gewoon een foutmelding geven. 

Verder kun je detecteren of de HTTP POST van een geldige bron komt:

De ING (inlog) gebruikt per sessie nieuwe namen voor formuliervelden. Open de inlog pagina maar in een browser en kijk hoe de namen zijn van de inputvakjes voor gebruikersnaam en wachtwoord. Als je een andere browser opent op diezelfde link dan zul je zien dat de inputvakjes andere namen hebben. Deze zijn gekoppeld aan de sessie van de gebruiker. Bij de ING in de sessie zal staan dat het veld &#039;username&#039; binnenkomt als &#039;eygadcnakleu&#039;. Klopt dat niet met de sessie, dan weet je dat de POST van een andere bron komt.

Een andere mogelijkheid is om elk HTML formulier een unieke random hash mee te geven in een hidden field. Die unieke hash plaats je ook in de sessie en laat je verlopen na een bepaalde tijd. Als je een formulier binnenkrijgt van de gebruiker en de unieke hash klopt niet met wat je in de sessie hebt staan, weet je dat het formulier vanaf een andere bron komt.
Zie bv http://www.codinghorror.c...srf-and-xsrf-attacks.html voor meer info.</description>
			<content:encoded><![CDATA[In de eerste plaats moet je je autorisatie goed hebben. Als gebruiker X pogingen doet om iets te beoordelen wat niet mag, bv door de url te wijzigen, dan moet je gewoon een foutmelding geven. <br>
<br>
Verder kun je detecteren of de HTTP POST van een geldige bron komt:<br>
<br>
De ING (<a href="https://mijn.ing.nl/internetbankieren/SesamLoginServlet" rel="external nofollow">inlog</a>) gebruikt per sessie nieuwe namen voor formuliervelden. Open de inlog pagina maar in een browser en kijk hoe de namen zijn van de inputvakjes voor gebruikersnaam en wachtwoord. Als je een andere browser opent op diezelfde link dan zul je zien dat de inputvakjes andere namen hebben. Deze zijn gekoppeld aan de sessie van de gebruiker. Bij de ING in de sessie zal staan dat het veld &#039;username&#039; binnenkomt als &#039;eygadcnakleu&#039;. Klopt dat niet met de sessie, dan weet je dat de POST van een andere bron komt.<br>
<br>
Een andere mogelijkheid is om elk HTML formulier een unieke random hash mee te geven in een hidden field. Die unieke hash plaats je ook in de sessie en laat je verlopen na een bepaalde tijd. Als je een formulier binnenkrijgt van de gebruiker en de unieke hash klopt niet met wat je in de sessie hebt staan, weet je dat het formulier vanaf een andere bron komt.<br>
Zie bv <a href="http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html" rel="external nofollow" title="http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html">http://www.codinghorror.c...srf-and-xsrf-attacks.html</a> voor meer info.]]></content:encoded>
			<dc:creator>Kalentum</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34443175#34443175</guid>
			<pubDate>Sat, 31 Jul 2010 15:12:56 GMT</pubDate>
		</item>
		<item>
			<title>Erkens</title>
			<link>https://gathering.tweakers.net/forum/list_message/34443058#34443058</link>
			<description>Afbeeldingen zou je bijvoorbeeld via PHP kunnen aanroepen als je deze niet voor iedereen toegankelijk wilt hebben. De AJAX-request gaan toch ook via PHP? En zal je hoogst waarschijnlijk ook via eenzelfde check willen sturen.
Daarnaast zijn er ook steeds meer mensen die het gemak van meerdere tabs in de browser gebruiken waardoor je ook rekening moet houden met &quot;oude&quot; pagina&#039;s die verversen. (alleen van toepassing als je de sessies via de URL mee stuurd, cookies zullen zeer waarschijnlijk wel goed gaan dan).</description>
			<content:encoded><![CDATA[Afbeeldingen zou je bijvoorbeeld via PHP kunnen aanroepen als je deze niet voor iedereen toegankelijk wilt hebben. De AJAX-request gaan toch ook via PHP? En zal je hoogst waarschijnlijk ook via eenzelfde check willen sturen.<br>
Daarnaast zijn er ook steeds meer mensen die het gemak van meerdere tabs in de browser gebruiken waardoor je ook rekening moet houden met &quot;oude&quot; pagina&#039;s die verversen. (alleen van toepassing als je de sessies via de URL mee stuurd, cookies zullen zeer waarschijnlijk wel goed gaan dan).]]></content:encoded>
			<dc:creator>Erkens</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34443058#34443058</guid>
			<pubDate>Sat, 31 Jul 2010 14:51:15 GMT</pubDate>
		</item>
		<item>
			<title>Guillome</title>
			<link>https://gathering.tweakers.net/forum/list_message/34443031#34443031</link>
			<description>Die vat ik niet Erkens. Bij een aanroep van een PHP pagina wordt eerst de PHP afgehandeld, dus de sessie gecontroleerd. Dan pas naar de client, en dan pas afbeeldingen en ajax requests.
Ik snap sowieso niet waarom afbeelden hierbij gemoeid zijn, het gaat niet via .htaccess toch?</description>
			<content:encoded><![CDATA[Die vat ik niet Erkens. Bij een aanroep van een PHP pagina wordt eerst de PHP afgehandeld, dus de sessie gecontroleerd. Dan pas naar de client, en dan pas afbeeldingen en ajax requests.<br>
Ik snap sowieso niet waarom afbeelden hierbij gemoeid zijn, het gaat niet via .htaccess toch?]]></content:encoded>
			<dc:creator>Guillome</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34443031#34443031</guid>
			<pubDate>Sat, 31 Jul 2010 14:44:41 GMT</pubDate>
		</item>
		<item>
			<title>Erkens</title>
			<link>https://gathering.tweakers.net/forum/list_message/34443004#34443004</link>
			<description>Avalaxy schreef op zaterdag 31 juli 2010 @ 16:33:
Tevens: elke keer als de user inlogt session_regenerate_id() gebruiken want sessions zijn, inderdaad, te capturen.Let daarbij wel op eventuele request die gelijktijdig gaan, zoals bijvoorbeeld met plaatjes of &quot;ajax&quot;-requests, want dat gaat gewoon fout vroeg of laat.</description>
			<content:encoded><![CDATA[<blockquote><div class="message-quote-div"><b><a href="https://gathering.tweakers.net/forum/list_message/34442982#34442982" rel="external" class="messagelink">Avalaxy schreef op zaterdag 31 juli 2010 @ 16:33</a>:</b><br>
Tevens: elke keer als de user inlogt session_regenerate_id() gebruiken want sessions zijn, inderdaad, te capturen.</div></blockquote>Let daarbij wel op eventuele request die gelijktijdig gaan, zoals bijvoorbeeld met plaatjes of &quot;ajax&quot;-requests, want dat gaat gewoon fout vroeg of laat.]]></content:encoded>
			<dc:creator>Erkens</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34443004#34443004</guid>
			<pubDate>Sat, 31 Jul 2010 14:39:08 GMT</pubDate>
		</item>
		<item>
			<title>Avalaxy</title>
			<link>https://gathering.tweakers.net/forum/list_message/34442982#34442982</link>
			<description>Hoe ik het altijd doe:

Voor elke correct ingelogde user een session aanmaken, vervolgens op elke pagina checken of er wel een open session voor die user is, zo niet -&gt; wegredirecten met PHP (niet met javascript!).

Tevens: elke keer als de user inlogt session_regenerate_id() gebruiken want sessions zijn, inderdaad, te capturen.</description>
			<content:encoded><![CDATA[Hoe ik het altijd doe:<br>
<br>
Voor elke correct ingelogde user een session aanmaken, vervolgens op elke pagina checken of er wel een open session voor die user is, zo niet -&gt; wegredirecten met PHP (niet met javascript!).<br>
<br>
Tevens: elke keer als de user inlogt session_regenerate_id() gebruiken want sessions zijn, inderdaad, te capturen.]]></content:encoded>
			<dc:creator>Avalaxy</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34442982#34442982</guid>
			<pubDate>Sat, 31 Jul 2010 14:33:03 GMT</pubDate>
		</item>
		<item>
			<title>Guillome</title>
			<link>https://gathering.tweakers.net/forum/list_message/34442900#34442900</link>
			<description>Hoi,

Ik vraag me af hoe veilig een script is die input krijgt vanuit POST gegevens.
Ik bouw een web-app en 1 van de onderdelen die goed beveiligd moet zijn is het beoordelen.

Stel: een deelnemer die praktisch geen rechten heeft, weet alles wat hij moet weten:
De url voor het beoordelen en alle variabele die je nodig hebt. Normaliter kan een deelnemer hier niet achter komen, maar je weet het maar nooit (een andere gebruiker die zijn PC open laat staan)
Hij maakt een eigen formulier op zijn eigen webserver, en post het.

Nu zijn er een aantal dingen. Ten eerste gaat dit nog niet lukken, want hij is ingelogd met te weinig rechten om te mogen beoordelen, maar het baart me toch zorgen dat hij op die manier in het script kan komen. Een gebruiker met voldoende rechten kan zo wel dingen beoordelen die niet voor hem bedoeld zijn..
Hoe kan ik een form/referer van buitenaf blokkeren? Of nog beter: hoe kan ik enkel referers accepteren die ik wil? HTTP_REFERER staat niet op elke webserver aan namelijk.

Ten tweede: zijn SESSIONS te hacken? Daar in staat of, en hoe je ingelogd bent met welke rechten. Nu wordt er in die scripts opnieuw de inlog gecontroleerd, maar hij haalt dat toch echt uit de sessies.

Nu wordt alles gelogd, dus mocht het een keer iemand lukken, is dat te achterhalen. Maar ik ben benieuwd hoe mensen hier er over denken.</description>
			<content:encoded><![CDATA[Hoi,<br>
<br>
Ik vraag me af hoe veilig een script is die input krijgt vanuit POST gegevens.<br>
Ik bouw een web-app en 1 van de onderdelen die goed beveiligd moet zijn is het beoordelen.<br>
<br>
Stel: een deelnemer die praktisch geen rechten heeft, weet alles wat hij moet weten:<br>
De url voor het beoordelen en alle variabele die je nodig hebt. Normaliter kan een deelnemer hier niet achter komen, maar je weet het maar nooit (een andere gebruiker die zijn PC open laat staan)<br>
Hij maakt een eigen formulier op zijn eigen webserver, en post het.<br>
<br>
Nu zijn er een aantal dingen. Ten eerste gaat dit nog niet lukken, want hij is ingelogd met te weinig rechten om te mogen beoordelen, maar het baart me toch zorgen dat hij op die manier in het script kan komen. Een gebruiker met voldoende rechten kan zo wel dingen beoordelen die niet voor hem bedoeld zijn..<br>
Hoe kan ik een form/referer van buitenaf blokkeren? Of nog beter: hoe kan ik enkel referers accepteren die ik wil? HTTP_REFERER staat niet op elke webserver aan namelijk.<br>
<br>
Ten tweede: zijn SESSIONS te hacken? Daar in staat of, en hoe je ingelogd bent met welke rechten. Nu wordt er in die scripts opnieuw de inlog gecontroleerd, maar hij haalt dat toch echt uit de sessies.<br>
<br>
Nu wordt alles gelogd, dus mocht het een keer iemand lukken, is dat te achterhalen. Maar ik ben benieuwd hoe mensen hier er over denken.]]></content:encoded>
			<dc:creator>Guillome</dc:creator>
			<guid isPermaLink="false">https://gathering.tweakers.net/forum/list_message/34442900#34442900</guid>
			<pubDate>Sat, 31 Jul 2010 14:12:27 GMT</pubDate>
		</item>
	</channel>
</rss>