Ingelogd als " Joz_1986"

[Priyantha Bleeker]

Ik zit gewoon lekker te surfen op het forum, en ik ga terug naar de index van het forum.
En er staat links boven in " Joz_1986" als ingelogde username.
Mijn voorkeuren zijn ook niet meer van toepassing op de index, ik zie nog maar een klein deel van het forum, voor de rest is alles ingeklapt.

Is er wat mis met het forum ? Of zou het aan mijn cookies liggen ? Die ik nu even ga deleten.

[justmental]

Als dit gewoon je eigen username is dan is het waarschijnlijk een cachingprobleempje (op je proxy?).

[Denker]

Cookies weggooien en je cache legen, dat zal helpen.

[Voutloos]

Wellicht handig om te vermelden of je al dan niet opnieuw ingelogd hebt nu.

[RM-rf]

Als je op school zit te GoTten, kan dat best gebeuren, dat iemand voor je is vergeten uit te loggen ....

Maak daar dan geen misbruik van, maar log uit, eventueel kun je het in SeM meldden en wij geven het dan door aan de gebruiker ...
Misbruik ervan maken _kan_ bestrafd worden ...

Het is overigens zeker aan te raden om bij het surfen op school er altijd op te letten dat je ook uitlogt

[Priyantha Bleeker]

Zo het werkt weer.
Ik heb alles uitgelogd, en heb de cache en cookies gewist

Ik werk achter mijn eigen laptop dus niemand heeft aan mijn computer gezeten, het zal wel iets in de proxy zijn geweest ofzo.

Ik melde dit niet voor niets he RM-rf, juist omdat ik niet ingelogd wil zijn in naam van iemand anders, ik heb mijn eigen username en betaal voor mijn tweakers.net abonnement.
Dat was dan ook mijn reden om het even gauw te melden.
Dus ik zou niet bestrafd worden neem ik aan doordat ik het even meld.

[.oisyn]

het klinkt idd als een proxyserver die jouw een outdated pagina voorschoteld van iemand anders. Een ctrl-f5 zou wel moeten werken.

[Priyantha Bleeker]

ja dat moet het zijn, want nu heb ik het probleem weer
Zit weer ingelogd als Joz_1986 terwijl ik toch echt "Priyantha Bleeker" als mijn username heb.
Ik heb net weer alles gewist enzo.

edit:
dit proxy hier zuigt dus big-time, werkt opeens wel en opeens niet meer, nu weer wel

edit:
Ik moet nu dus elke keer als ik op de index kom ctrl+f5 indrukken om de pagina werkend te houden...

[ Voor 43% gewijzigd door Priyantha Bleeker op 18-10-2005 13:14 ]

[crisp]

Lekker, een proxy die dynamische pagina's met no-cache headers toch cached
Erg makkelijk om dan iemands sessie te kapen; ReactID's liggen blijkbaar voor het oprapen...

[curry684]

Die proxy is echt enorm fout geconfigureerd, en er zitten zo te zien heel veel gebruikers van het Alfa College op (die Joz_1986 is een schoolgenoot van je). Ik zou eens even linea recta een paar sysadmins over schoppen: tis nu nog relatief onschuldige data van een forum maar er zullen vast ook mensen internetbankieren vanaf school of dingen bestellen...

[ Voor 7% gewijzigd door curry684 op 18-10-2005 13:15 ]

[Priyantha Bleeker]

Ja, volgens mij is dit niet fijn nee
Ze gebruiken hier iig iets van een Microsoft proxy server...

Hier even de output van een nmap

code:

For OSScan assuming port 13 is open, 1 is closed, and neither are firewalled
Host 192.168.1.1 appears to be up ... good.
Interesting ports on 192.168.1.1:
(The 1658 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE
13/tcp   open  daytime
21/tcp   open  ftp
37/tcp   open  time
80/tcp   open  http
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
808/tcp  open  ccproxy-http
809/tcp  open  unknown
1025/tcp open  NFS-or-IIS
1080/tcp open  socks
MAC Address: 00:02:B3:8C:51:3B (Intel)
Device type: general purpose
Running: Microsoft Windows NT/2K/XP
OS details: Microsoft Windows XP Pro SP1/SP2 or 2000 SP4
OS Fingerprint:
TSeq(Class=TR%IPID=I%TS=0)
T1(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=MNWNNT)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
TCP ISN Seq. Numbers: 3E38E6BB 3BE03C0D CA1DB72 C3CD5A70 DA4438B5 E76751E6
IPID Sequence Generation: Incremental

Nmap finished: 1 IP address (1 host up) scanned in 1.970 seconds
               Raw packets sent: 1683 (67.9KB) | Rcvd: 1683 (77.5KB)

[ Voor 89% gewijzigd door Priyantha Bleeker op 18-10-2005 13:15 ]

[curry684]

Ik heb met MS Proxy, ondanks dat het om andere redenen een rukproxy is, deze problemen nog nooit gehad. Ik vermoed dat ze iets van aggressieve caching expliciet aan hebben gezet.

[Priyantha Bleeker]

Ik heb het aan mijn docent Cisco doorgegeven.
Die gaat het doorgeven aan de sysadmins.
Ik zal zometeen ook nog even naar een sysadmin gaan.
Dit is best wel ernstig, ook omdat ik zelf hier wel eens heb ge-internetbankiert.
Kijk deze forum gegevens zijn niet zo heel erg erg, maar andere gevoelige informatie...

[.oisyn]

crisp schreef op dinsdag 18 oktober 2005 @ 13:14:
Lekker, een proxy die dynamische pagina's met no-cache headers toch cached
Erg makkelijk om dan iemands sessie te kapen; ReactID's liggen blijkbaar voor het oprapen...

Nou vind ik het überhaupt erg lomp dat reactid's in de geproduceerde output voorkomen. Ze worden naar ik meen om twee redenen gebruikt: in de linkjes naar de xml/rss feeds, en als hidden input fields om XSS te voorkomen. Die eerste wordt wat problematisch (hoewel je evt. een aparte id voor die feeds zou kunnen gebruiken, dan blijft het aantal mogelijkheden wat je ermee kunt doen nog beperkt), maar voor die laatste is uiteraard niet per se je reactid nodig.

[ Voor 12% gewijzigd door .oisyn op 18-10-2005 14:08 ]

[crisp]

Feeds werken prima zonder ReactID, alleen zie je dan niet de besloten fora - tenzij je een feedreader gebruikt vanuit een browser die ook je cookie meestuurd.

Die hidden ReactID fields zijn voor zover ik kan zien idd redelijk nutteloos. Ik zie niet hoe dat XSS zou moeten voorkomen, hooguit zou het als soort token kunnen dienen om POST-flooding te voorkomen, maar dan zou het per request uniek moeten zijn (en dat is het niet).

[.oisyn]

Zonder die reactid in hidden inputs kan iemand anders dus een submit doen onder mijn naam als ik op zijn website kom. Maar omdat de reactid nodig is bij handelingen, en die persoon mijn reactid niet weet, lukt dat dus niet. Maar uiteraard hoeft hier niet per se het reactid voor gebruikt te worden, het kan ook een ander id zijn (desnoods MD5(reactid), maar dat is weer wat te onveilig imho als iemand weet dat dat idd de MD5 van je reactid is)

[Sabbi]

.oisyn schreef op dinsdag 18 oktober 2005 @ 14:39:
Zonder die reactid in hidden inputs kan iemand anders dus een submit doen onder mijn naam als ik op zijn website kom. Maar omdat de reactid nodig is bij handelingen, en die persoon mijn reactid niet weet, lukt dat dus niet. Maar uiteraard hoeft hier niet per se het reactid voor gebruikt te worden, het kan ook een ander id zijn (desnoods MD5(reactid), maar dat is weer wat te onveilig imho als iemand weet dat dat idd de MD5 van je reactid is)

???? Je reactid staat gewoon in een cookie. Dat hoef je toch niet elke keer mee te sturen dus? en hoe kan die website aan jouw cookies komen?

[curry684]

Het gaat hier niet om een website maar een proxy, oftewel een klassieke "man-in-the-middle" situatie.

[Sabbi]

.oisyn schreef op dinsdag 18 oktober 2005 @ 14:39:
Zonder die reactid in hidden inputs kan iemand anders dus een submit doen onder mijn naam als ik op zijn website kom.

Oisin zegt hier dat zonder reactid vanaf de server iemand je account kan overnemen als je op zijn hippe website komt... ik zeg dat dat onzin is... een proxy is inderdaad wat anders. (daarom quootte ik hem ook )

[ Voor 5% gewijzigd door Sabbi op 18-10-2005 17:23 ]

[crisp]

Ik zal het morgen eens opnemen met Parse of er echt redenen zijn om die hidden inputs met ReactID te behouden; volgens mij is het nutteloos aangezien die toch met je cookie meegestuurd wordt (en die staat op het tnet domein, dus een andere site kan daar niet aankomen).

Vwb de rss en xml links ben ik al een tijdje genegen om per default de reactid daar uit te slopen.

[JHS]

Kunnen mbt de rss/xml links daar niet desnoods twéé linkjes worden neergezet, één set met een ander plaatje en desnoods uitleg incl. reactID, één set zonder. Kunnen mensen die het gebruiken om besloten fora te bekijken daar toch "als vanzelf" wél gebruik van maken .

[crisp]

JHS schreef op dinsdag 18 oktober 2005 @ 17:53:
Kunnen mbt de rss/xml links daar niet desnoods twéé linkjes worden neergezet, één set met een ander plaatje en desnoods uitleg incl. reactID, één set zonder. Kunnen mensen die het gebruiken om besloten fora te bekijken daar toch "als vanzelf" wél gebruik van maken .

Vanuit je browser kan je altijd gebruik maken van die links aangezien dan je cookie meegestuurd wordt; het wordt een ander verhaal als je zo'n link in een feedreader zet.

[Zwelgje]

das geen msproxy of isa hoor.. tis ccproxy

*gelukkig maar*
* Zwelgje heeft een chronisch vertrouwen in MS software en dat is bij deze niet beschadigd

[JHS]

crisp schreef op dinsdag 18 oktober 2005 @ 17:57:
[...]Vanuit je browser kan je altijd gebruik maken van die links aangezien dan je cookie meegestuurd wordt; het wordt een ander verhaal als je zo'n link in een feedreader zet.

Ah, oké .

[Voutloos]

crisp schreef op dinsdag 18 oktober 2005 @ 17:57:
[...]

Vanuit je browser kan je altijd gebruik maken van die links aangezien dan je cookie meegestuurd wordt; het wordt een ander verhaal als je zo'n link in een feedreader zet.

Ik speel de laatste tijd een beetje met readers en een zelfgemaakt brouwseltje en zou het toch een fijn idee vinden als er een minder kritiek RSS/XML_sessie-id zou zijn (het idee dat .oisyn hierboven aandraagt).

[Verwijderd]

Sabbi schreef op dinsdag 18 oktober 2005 @ 17:22:

Oisin zegt hier dat zonder reactid vanaf de server iemand je account kan overnemen als je op zijn hippe website komt... ik zeg dat dat onzin is... een proxy is inderdaad wat anders. (daarom quootte ik hem ook )

Ik zeg dat het geen onzin is. Ik heb al aangetoond hoe het forum te misbruiken is als je iets dergelijks weglaat.

Wat er precies gebruikt wordt is niet belangrijk, als het aan de volgende voorwaarden voldoet. Het ReactID voldoet aan alle eisen, maar heeft als nadeel dat je meteen alles kunt als je dat id comprimiset. Je kunt ook iets anders nemen, bijvoorbeeld een MD5 van een React ID met een salt, maar eigenlijk heb je (door een brakke proxy) iets nodig dat per request uniek is. Maar met een brakke proxy werkt het forum dan helemaal voor geen meter omdat React continu "hackpogingen" zal detecteren, en de sessies zal moeten beëindigen.

Kortom, een ReactID voldoet als proxies goed werken. Als dat niet zo is, moet je iets hebben dat nog "beter" is dan de ReactID.

[crisp]

Voutloos schreef op dinsdag 18 oktober 2005 @ 17:59:
[...]

Ik speel de laatste tijd een beetje met readers en een zelfgemaakt brouwseltje en zou het toch een fijn idee vinden als er een minder kritiek RSS/XML_sessie-id zou zijn (het idee dat .oisyn hierboven aandraagt).

Waar .oisyn denk ik op doelt is meer een challenge-response achtig mechanisme om te kijken of er wel een geldig request is voorafgegaan aan een bepaalde respons. Doorgaans gebruik je daar eenmalige tokens voor. Een dergelijk systeem hanteren we op de frontpage om geautomatiseerde replies (spam) en dubbelposten te voorkomen. Dat staat los van een sessie-id die jouw identiteit herbergt bij een actie.
Ik zie niet hoe je een 'minder kritieke' sessie-id zou kunnen construeren aangezien daar toch je rechten aan hangen.

[ Voor 5% gewijzigd door crisp op 18-10-2005 18:05 ]

[Verwijderd]

Nu ik er nog even langer over nadenk, je hebt een unieke key nodig voor verschillende niveau's. Een key om fora te kunnen bekijken, en een key om te kunnen posten. Hoe die key's gemaakt worden is niet belangrijk, die mogen gewoon random gegenereerd worden. Zolang de server maar weet welke keys een user heeft.

Overigens is dit wel service van React, aangezien je alleen tegen jezelf en tegen brakke netwerken wordt beschermd. Het forum zelf wordt er niet veiliger of onveiliger mee.

offtopic:
En vergeet even niet om die HTML rechten uit te zetten. Dit was zomaar weer een mogelijkheid om havoc aan te richten als er toevallig iemand met HTML rechten was ingelogd via die proxy.

[Voutloos]

crisp schreef op dinsdag 18 oktober 2005 @ 18:04:
[...]
Ik zie niet hoe je een 'minder kritieke' sessie-id zou kunnen construeren aangezien daar toch je rechten aan hangen.

.oisyn schreef op dinsdag 18 oktober 2005 @ 14:06:
Ze worden naar ik meen om twee redenen gebruikt: in de linkjes naar de xml/rss feeds, en als hidden input fields om XSS te voorkomen. Die eerste wordt wat problematisch (hoewel je evt. een aparte id voor die feeds zou kunnen gebruiken, dan blijft het aantal mogelijkheden wat je ermee kunt doen nog beperkt),

Dat id zou dan alleen maar voor de feeds zijn, met alleen maar leesrechten. Wel heb je gelijk dat nog steeds mijn leesrechten voor de besloten fora te grabbel liggen als iemand mijn systeem compromiteert. (Misschien is het alleen maar goed als er ook postrechten zijn omdat crew dan eerder afwijkend gedrag kan constateren. ) Al met al is het geen dringende feature request. Wel is het reactid vaak genoeg onderwerp van discussie als het op de feeds aankomt, dus dit idee mag imo wel meegenomen worden in die discussie.

[crisp]

Op basis van je echte ReactID is natuurlijk met een (geheime) salt wel weer een uniek ID te maken waarmee je read-only access via /rss en /xml kan geven, maar waarmee je verder weinig kan (en zonder de geheime salt te weten is het dan erg lastig om daar het echte ReactID uit te construeren). Punt is alleen dat een dergelijke select in de sessie-tabel nogal zwaar is:

code:

SELECT UserID FROM Sessions WHERE MD5(CONCAT(SessionID, '$secretsalt')) = '$RSSID'

Je zou dan eigenlijk ook al UserID in de link moeten opnemen om het te versnellen - dat maakt ook duidelijker dat het een gepersonaliseerde link is waarmee je op moet passen.
Verder zou je dan ook een 1-item RSS/XML met een 'geen toegang' melding terug kunnen geven in het geval de RSSID niet (meer) geldig is.

[ Voor 12% gewijzigd door crisp op 18-10-2005 18:31 ]

[Voutloos]

Dat lijkt me inderdaad op deze manier geen handige query. . UserId erbij zetten is niet eens zo'n gek idee, dan kan ook meteen die user door iedereen gewaarschuwd worden als een linkje met zijn rssid ergens opduikt.