[feat] automatisch ReactID's laten wegfilteren uit berichten

[elnino]

Naar aanleiding van ReactID misbruik en de gevolgen. Een van de crewleden had per ongeluk zijn ReactID gelekt en enkele gebruikers maakten hier misbruik van.

Het geval wil dat ReactID's nogal gemakkelijk gelekt kunnen worden: als je per ongeluk een ReactID van een XML- of RSS-link meekopieert in een topic gaat dat meestal zonder dat je dat merkt.

Zou er daarom geen mogelijkheid in React ingebouwd kunnen worden dat er automatisch wordt gecontroleerd of er geen ReactID's van de betreffende gebruiker in het bericht te vinden zijn. Meestal hebben gebruikers niet meer dan twee of drie verschillende sessie's openstaan, dus het zal zover ik kan overzien geen wereldschokkende DB-query gaan worden. Desnoods controleer je alleen maar op de huidige, actieve ReactID.

Indien er een ReactID in het bericht te vinden is, kan de gebruiker gewaarschuwd worden of kan hij vervangen worden door iets als '<knip>'.

Nogmaals: misbruik is niet te voorkomen, en dit soort kleine vergissingen ook niet, maar de kans erop moet wel zo klein mogelijk gemaakt worden.

Ik heb gekeken in de history van dit forum en kon geen vergelijkbaar voorstel vinden. Vandaar dit topic.

[m-m]

hoe wou je dit onderscheiden? Een reactID is een volstrekt willekeurige alfanumerieke string, hoe ga je dit onderscheiden van een normaal woord?
Oh zo, je wou van elk woord kijken of het toevallig de reactid van die gebruiker is, lijkt me eigenlijk aardig belastend?

[ Voor 35% gewijzigd door m-m op 20-11-2004 01:24 ]

[elnino]

Dat valt volgens mij nog wel mee. Stel een gebruiker heeft vijf ReactID's. Deze kunnen door middel van een query uit de db gehaald worden. Vervolgens kan er met een simpele zoek- of zoek-en-vervang-functie bepaald worden of er wel of geen ReactID in staat (in PHP bijvoorbeeld str_replace()). Het kost wat extra db-kracht, maar volgens mij niet zoveel meer.

[Verwijderd]

Is dit niet een brug te ver? Als een 'normale user' z'n react-id post, is er niets aan het hand. Diegene die er misbruik van maakt, kan temp-banned worden oid.

Modjes etc moeten gewoon hun react-id niet posten..

Je zou eventueel een tussenvorm kunnen maken, en alleen posts van personen met 'bijzondere rechten' filteren op de betreffende react-id's. Is al een stuk minder belastend.

[ Voor 6% gewijzigd door Verwijderd op 20-11-2004 01:39 ]

[elnino]

Desnoods voer je alleen maar een check uit op je huidige, actieve sessie, want die ReactID is toch al beschikbaar voor het script (want die is te vinden in de cookie of in de query string), ik denk dat de meeste ongelukken toch gebeuren met de huidige sessie. Het toepassen van str_replace() is iets wat, in mijn ogen, vergeleken met andere taken, nauwelijks vertragend zal gaan werken.

[Verwijderd]

Lijkt mij een stuk simpeler om te checken op de aanwezigheid van [ReactID= gevolgd door een 32 cijferige HEX code] dan een extra load om te checken of het wel om een actieve sessie gaat.

Eventueel kun je het op dezelfde manier toepassen zoals nu de self-quote wordt afgehandeld: de intelligentie/afhandeling aan de gebruiker overlaten (na een informerend schermpje wat er zo gevaarlijk aan die ReactID is).

[crisp]

Er is al aan Parse gevraagd of de ReactID uit de RSS en XML links verwijderd kan worden.
Als hieraan niet voldaan kan worden, of als dat om andere redenen niet wenselijk zou zijn dan zou ik middels de RML inderdaad ook ReactID's kunnen filteren of vervangen door ReactID=xxxxxxxxxx

In het uitzonderlijke geval dat zo'n vervanging niet wenselijk is kan je dan altijd nog de [ norml] tag hanteren

[ Voor 18% gewijzigd door crisp op 20-11-2004 10:31 ]

[Xander]

Hmm, dit soort dingen doen je toch weer even nadenken... volgens mij heb ik ook weleens volledige topics gesaved als HTML, daar zit dan kennelijk ook de ReactID bij door die linkjes naar de RSS/XML feed onderin...

Nouja, ben nadien al vast wel een keertje uitgelogd (net nog een keer voor de zekerheid) en heb mijn ReactID gelocked aan mijn IP... maar toch... eventjes iets om bij stil te staan...

[crisp]

http://crew.tweakers.net/crisp/newlayout/index.html
staat mijn ReactID in Gelukkig was dat een sessie op een niet-publieke server

[CrashOne]

Koppel een reactID gewoon altijd aan een ip, lastig voor mobiele aps, maar een keer extra inloggen is toch niet zo erg?

[Erkens]

CrashOne schreef op zaterdag 20 november 2004 @ 10:41:
Koppel een reactID gewoon altijd aan een ip, lastig voor mobiele aps, maar een keer extra inloggen is toch niet zo erg?

ik vind dat dat setting standaard aan moet, en dat je hem zelf uit moet kunnen zetten, dan weet je zelf dat je daar op moet letten

[Glabbeek]

Erkens schreef op zaterdag 20 november 2004 @ 10:42:
[...]

ik vind dat dat setting standaard aan moet, en dat je hem zelf uit moet kunnen zetten, dan weet je zelf dat je daar op moet letten

Daar ben ik het mee eens. Zeker bij het inlogform bovenaan de topicindex zou het handig zijn als de IP-check aan zou staan, aangezien je daar niet de mogelijkheid hebt hem zelf aan te zetten. Ik gebruik eigenlijk altijd dat form, en kwam er net pas achter dat de IP-check dan niet aan staat.

[Morax]

CrashOne schreef op zaterdag 20 november 2004 @ 10:41:
Koppel een reactID gewoon altijd aan een ip, lastig voor mobiele aps, maar een keer extra inloggen is toch niet zo erg?

Dit is niet alleen irritant voor mobiele aps, maar ook voor mensen waarbij de provider eens per X dagen het IP van hun gebruikers wijzigen (Vooral in België het geval, NL valt dan nog mee).

Ik ben het dan meer eens met bovenstaande oplossing: Standaard vinkje aan zetten, en alleen uitzetten als dat nodig is

[Xander]

Morax schreef op zaterdag 20 november 2004 @ 14:16:
[...]


Dit is niet alleen irritant voor mobiele aps, maar ook voor mensen waarbij de provider eens per X dagen het IP van hun gebruikers wijzigen (Vooral in België het geval, NL valt dan nog mee).

Het is ook echt rampzalig als je dan eens per X dagen opnieuw je wachtwoord in moet tikken??

Liever dat dan een mogelijk beveiligingsrisico eigenlijk...

[Erkens]

XanderH schreef op zaterdag 20 november 2004 @ 14:59:
[...]


Het is ook echt rampzalig als je dan eens per X dagen opnieuw je wachtwoord in moet tikken??

Liever dat dan een mogelijk beveiligingsrisico eigenlijk...

kijk, sommige providers hebben een dynamisch ip adres en bij iedere keer dat je verbinding maakt krijg je een nieuw ip adres. En dus iedere keer moet je je wachtwoord opnieuw invoeren, en ja ook hier zitten beveiligings risico's aanvast, je moet tenslotte iedere keer dat wachtwoord invoeren. De mens blijft altijd de zwakste schakel, maar een beetje gebruiksgemak mag toch wel. Standaard gelocked op IP, en handmatig niet. Heb je direct een iets betere "beveiliging" en iedereen hoeft niet iedere keer opnieuw in te loggen

[Spider.007]

Ik denk dat dit ook te ver gaat. Het is nog steeds mogelijk dat iemand zijn ReactID in een image laat staan ofzo. Of moeten we straks ook gaan filteren op mogelijke IRC channel keys en andere wachtwoorden? Over dat vastzetten op IP; misschien inderdaad standaard aan; maar maak het niet onuitschakelbaar (/me zit achter groep proxies en heeft bij ieder request een random IP)

[kamerplant]

Enkel standaard de IP lock aan, daarmee ben je een enorm groot deel van het veiligheidsrisico kwijt. Ik heb me altijd al verbaast waarom dit standaard uit stond.

[We Are Borg]

DataBeest schreef op zaterdag 20 november 2004 @ 17:37:
Enkel standaard de IP lock aan, daarmee ben je een enorm groot deel van het veiligheidsrisico kwijt. Ik heb me altijd al verbaast waarom dit standaard uit stond.

Ik denk dat het nog is overgenomen uit het tijdperk dat een 56K modem nog best gewoon was

[elnino]

Trouwens, een ander vraagje over het ReactID: als ik gebruik maak van een ReactID in een urllink (dus /forum/list_topics/1?reactID=fd34etc), is dan in de userimages niet gemakkelijk de HTTP_REFERER te achterhalen en daarmee ook niet de Reactid? Zelfde geldt voor geplaatste links op een pagina: aan de REFERER is als het goed is te zien welke ReactID een gebruiker heeft.

offtopic:
Even een testlink naar een lokale phpinfo om het uit te testen: [url=http://localhost/phpinfo.php][..][/url]

edit: Dit is dus mogelijk, als jij een pagina opent vanuit een bepaalde pagina met je ReactID in de querystring, wordt deze ID ook als REFERER meegegeven. Dit gebeurt waarschijnlijk dus ook met afbeeldingen. Overigens heb ik na de test mezelf direct uitgelogd, zodat de betreffende ReactID direct is komen te vervallen, mocht er een usericon zijn die toevallig referers logt.

Maar het gebruik van ReactID's heeft dus nogal wat haken en ogen, waar je zeker mee moet oppassen.

[ Voor 33% gewijzigd door elnino op 20-11-2004 21:56 ]

[Xander]

elnino schreef op zaterdag 20 november 2004 @ 21:48:
Trouwens, een ander vraagje over het ReactID: als ik gebruik maak van een ReactID in een urllink (dus /forum/list_topics/1?reactID=fd34etc), is dan in de userimages niet gemakkelijk de HTTP_REFERER te achterhalen en daarmee ook niet de Reactid? Zelfde geldt voor geplaatste links op een pagina: aan de REFERER is als het goed is te zien welke ReactID een gebruiker heeft.

offtopic:
Even een testlink naar een lokale phpinfo om het uit te testen: [url=http://localhost/phpinfo.php][..][/url]

edit: Dit is dus mogelijk, als jij een pagina opent vanuit een bepaalde pagina met je ReactID in de querystring, wordt deze ID ook als REFERER meegegeven. Dit gebeurt waarschijnlijk dus ook met afbeeldingen. Overigens heb ik na de test mezelf direct uitgelogd, zodat de betreffende ReactID direct is komen te vervallen, mocht er een usericon zijn die toevallig referers logt.

Maar het gebruik van ReactID's heeft dus nogal wat haken en ogen, waar je zeker mee moet oppassen.

Ik krijg als ik een reactID meegeef die anders niet te zien in dit plaatje...?

[Erkens]

XanderH schreef op zaterdag 20 november 2004 @ 22:34:
[...]


Ik krijg als ik een reactID meegeef die anders niet te zien in dit plaatje...?

[afbeelding]

wel als je je ReactID via de URL meestuurt

[Xander]

Erkens schreef op zaterdag 20 november 2004 @ 22:36:
[...]

wel als je je ReactID via de URL meestuurt

Hm, dat deed ik dus, alleen ik was vergeten om even Ctrl-F5 te doen

Anyway, nu met een "Header("Cache-Control: no-cache, must-revalidate"); " erbij zie ik hem idd wel ja..

Denk alleen niet dat deze toepassing irl veel voorkomt? Een ReactID via de URL meesturen als je een topic bekijkt? Bij XML feeds enzo kan ik het me voorstellen, bij normaal GoTten eigenlijk niet

[ Voor 26% gewijzigd door Xander op 20-11-2004 22:38 ]

[elnino]

XanderH schreef op zaterdag 20 november 2004 @ 22:37:
Denk alleen niet dat deze toepassing irl veel voorkomt? Een ReactID via de URL meesturen als je een topic bekijkt? Bij XML feeds enzo kan ik het me voorstellen, bij normaal GoTten eigenlijk niet

Dat vraag ik me eerlijk gezegd ook af. Ik kan me voorstellen dat mensen het gebruiken indien ze geen cookies kunnen of willen setten. Alleen de ReactID wordt niet automatisch onthouden, je zult hem er dus telkens achter moeten zetten. Maar ik heb zelf geen zicht in hoeverre dit gebruikt wordt, maar dat het een potentieel veiligheidsrisico met zich meebrengt is evident, lijkt me.

[crisp]

* crisp test: http://gathering.tweakers...xxxxxxxxxxxxxxxxxxxxxxxxx

[crisp]

werkt \o/