Cross-site HTTP 401 Unauthorized - Softwareontwikkeling

vrijdag 6 september 2013 08:36

Acties:

Topicstarter

Eerst iets over de site zelf: We hebben een vrij grote communititysite welke tevens een forum heeft. De site zelf is volledig in-house gemaakt, terwijl het forum vBulletin is. (Overigens zijn er plannen om vBulletin te vervangen, maar dat ter zijde)

De laatste paar weken worden wij geteisterd door iemand die continue door probeert achter de wachtwoorden van users te komen. De meest gebruikt methode is door een post op de site of forum te plaatsen met een plaatje erin. Dit 'plaatje' resulteert dan in een HTTP 401, wat er voor zorgt dat er een authentication promt bij de eindgebruiker komt...

Nu had ik al een paar methoden bedacht om zo iets tegen te gaan:

Controleer het plaatje als het gepost wordt. Dit zorgt wel dat op dat moment het plaatje werkt, maar dan kan diegene nog steeds deze vervangen door iets anders met een HTTP 401 response...
Doe alle externe usercontent sideloaden. Dit zou er voor moeten zorgen dat er niet zomaar een authentication promt tevoorschijn komt, maar hier heb ik geen concrete dingen over gevonden. Misschien is dit gewoon een belabberd idee?
Verbied externe images. Dat zou opzich wel werken, maar voor de gebruikerservaring werkt dit juist averechts. Ook niet echt de ideale oplossing. (Note: Op dit moment staat deze tag op het forum uit vanwege dit probleem)
Alle content zelf hosten. Dat kan, maar kost een enorme hoeveelheid ruimte, welke we niet hebben.

Wat ik dus eigenlijk zoek, is een methode om te zorgen dat er geen authentication promt van een externe site tevoorschijn komt. Hoe pakken jullie dit aan, en hoe kan ik dit voorkomen?

ps. De gebruikers worden op het dit moment opgevoed om daar geen passwords in te voeren

Rare vogel in spe

vrijdag 6 september 2013 12:22

Acties:

Tsjilp

RS[I]ds

die user bannen?

Raar... Is zo gek nog niet

vrijdag 6 september 2013 13:00

Acties:

Xesxen

Topicstarter

Die user is al lang verbannen hoor

Ik zoek naar een oplossing om dat te voorkomen, i.p.v. 'de brand te blussen'

Rare vogel in spe

vrijdag 6 september 2013 13:35

Acties:

Merethil

Kan je niet de link eerst volgen en checken of hij op een HTTP 400 uitkomt? Zo niet, dan weg?
Zoiets lijkt mij denk ik het makkelijkst om ook andere dingen af te vangen, waaronder niet-werkende links e.d.

Ben niet helemaal bekend met hoe je dat kan doen, maar volgens mij kan je een request naar die server doen en de HTTP code die de server teruggeeft uitlezen, toch?

vrijdag 6 september 2013 13:57

Acties:

Xesxen

Topicstarter

Dat heb ik al reeds bij punt 1 opgeschreven, namelijk opvragen en controlleren. Dit neemt niet weg dat het plaatje daarna vervangen kan worden op die externe server

Rare vogel in spe

zaterdag 7 september 2013 11:04

Acties:

Blue-eagle

Wat ik zou overwegen is simpelweg alle plaatjes weigeren die niet van trusted domains zijn. Bekende image sharing websites (zoals imgur.com) kan je bijvoorbeeld gewoon toestaan, dus whitelisten.

Overige plaatjes kan je 2 dingen mee doen:

1. Melding geven: "Onbekende bron - upload bij imgur.com of ietsanders.nl";
2. Kijken of je zelf client-side het plaatje kan uploaden via de API van imgur.com (http://api.imgur.com/).

Persoonlijk zou ik de bron van het plaatje gewoonweg uploaden naar onze eigen host (AWS), en vervolgens het plaatje vanaf onze eigen server weergeven.

Als laatste optie kan je ook alle plaatjes iedere keer dat ze worden weergegeven opnieuw controleren. Maar dat vreet resources. Opvoeden van je gebruikers, zou ik zeggen

zaterdag 7 september 2013 14:10

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Blue-eagle schreef op zaterdag 07 september 2013 @ 11:04:
Persoonlijk zou ik de bron van het plaatje gewoonweg uploaden naar onze eigen host (AWS), en vervolgens het plaatje vanaf onze eigen server weergeven.

Dat is een wespennest waar ik m'n hand niet in zou steken. Je krijgt allerlei issues met auteursrecht etc. (effectief maak jij een kopie van plaatjes en ga je ongezien (want: geautmatiseerd) god-knows-what hosten; dan is een een kwestie van je brievenbus in de gaten houden tot je een keer een boze brief van een advocaat aantreft).

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

zaterdag 7 september 2013 21:49

Acties:

Xesxen

Topicstarter

Dat is inderdaad dan weer een nieuw issue, en zo'n risico's willen we eigenlijk niet lopen. (Neemt niet weg dat we simpelweg de ruimte hiervoor niet hebben.)

Rare vogel in spe

dinsdag 10 september 2013 14:20

Acties:

Blue-eagle

RobIII schreef op zaterdag 07 september 2013 @ 14:10:
[...]

Dat is een wespennest waar ik m'n hand niet in zou steken. Je krijgt allerlei issues met auteursrecht etc. (effectief maak jij een kopie van plaatjes en ga je ongezien (want: geautmatiseerd) god-knows-what hosten; dan is een een kwestie van je brievenbus in de gaten houden tot je een keer een boze brief van een advocaat aantreft).

Hmm. Ik zie daar niet zo'n probleem in eigenlijk, een goede disclaimer, terms of use, en een DMCA notitie met gegevens om copyright claims mee af te handelen zouden al voldoende moeten zijn. Websites als imgur.com doen dat ook op die manier.

Maar als dat geen optie is (het is geen optie lees ik

) zou ik gewoon overschakelen naar het simpelweg whitelisten van een aantal domeinen, en de rest blokkeren.

dinsdag 10 september 2013 14:50

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Blue-eagle schreef op dinsdag 10 september 2013 @ 14:20:
Websites als imgur.com doen dat ook op die manier.

Dat is dan ook (een groot deel van) hun core-business; als dit, zoals ik verwachtte, voor TS maar een klein onderdeel van 't geheel is en je liever bezig houdt met je eigen core-business i.p.v. takedown notices afhandelen dan is dat, imho, dus zeker iets wat je even moet overwegen

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

woensdag 11 september 2013 15:54

Acties:

reshi

Stukje javascript dat probeert de afmeting van de externe afbeelding op te halen? http://stackoverflow.com/...sions-of-a-external-image

Of kijkt of de afbeelding bestaat? http://stackoverflow.com/...ery-check-if-image-exists

Als dat faalt haal je de img tag uit je source?

Performance technisch voor het laden van je pagina een drama, maar dat is waarschijnlijk toch al niet al te snel omdat er extern afbeeldingen opgehaald worden.

woensdag 11 september 2013 16:25

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

reshi schreef op woensdag 11 september 2013 @ 15:54:
Stukje javascript dat probeert de afmeting van de externe afbeelding op te halen? http://stackoverflow.com/...sions-of-a-external-image

Dat werkt heel leuk als de image bestaat en/of 404 geeft, maar een 401 vang je er niet mee.

reshi schreef op woensdag 11 september 2013 @ 15:54:
Of kijkt of de afbeelding bestaat? http://stackoverflow.com/...ery-check-if-image-exists

Geldt 'tzelfde voor

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

woensdag 11 september 2013 22:06

Acties:

BasieP

http://jsfiddle.net/c3SZg/ <-- die werkt wel

(in FF en chrome iig)

en hier een jquery variant
http://jsfiddle.net/j44DA/

[ Voor 28% gewijzigd door BasieP op 11-09-2013 22:34 ]

This message was sent on 100% recyclable electrons.

maandag 16 september 2013 11:44

Acties:

Bosmonster

*zucht*

reshi schreef op woensdag 11 september 2013 @ 15:54:
Als dat faalt haal je de img tag uit je source?

Performance technisch voor het laden van je pagina een drama, maar dat is waarschijnlijk toch al niet al te snel omdat er extern afbeeldingen opgehaald worden.

Dat gaat nooit 100% werken, aangezien de browser een stuk sneller is tegenwoordig dan je javascript kan uitvoeren. Grote kans dat de src requests dus al de deur uit zijn voordat je javascript erlangs komt.

Dan zou je dus andere rare fratsen uit moeten halen, zoals de src in een data-attribuut zetten oid en pas in de src zetten als het goed is. Maar dat heeft weer gevolgen voor SEO en toegankelijkheid.

Enige wat goed werkt hierbij is een goed moderatiebeleid denk ik.

dinsdag 17 september 2013 09:57

Acties:

Hiroj

Mijn advies is om eerder genoemde oplossing in de vorm van een vertrouwde websites whitelist te maken.
Ik weet niet of vBulletin dergelijk support ervoor heeft, anders is het wel eenvoudig zelf te maken.

Het kost aan de andere kant wel een hoop tijd om een lijst te maken van goede kwalitatieve media upload websites, maar dan verhelp je het probleem ook gelijk.

dinsdag 17 september 2013 21:42

Acties:

Xesxen

Topicstarter

Dan voorkom je het inderdaad mee, maar ikzelf (persoonlijk) upload vaak images naar mijn eigen hosting en gebruik deze op o.a. T.net. Dat zou dus betekenen dat je legitieme gebruikers features afneemt...

Rare vogel in spe

dinsdag 17 september 2013 23:27

Acties:

Blue-eagle

Xesxen schreef op dinsdag 17 september 2013 @ 21:42:
Dan voorkom je het inderdaad mee, maar ikzelf (persoonlijk) upload vaak images naar mijn eigen hosting en gebruik deze op o.a. T.net. Dat zou dus betekenen dat je legitieme gebruikers features afneemt...

Blacklisten dan; domeinen voor dit soort "hackers" raken op een gegeven moment ook wel op. IP-adressen wel standaard weren. Zodra iemand een plaatje toevoegt in zijn reactie gewoon het URL bekijken en een tekstje weergeven: "Dit domein is ons niet bekend, in verbang met veiligheid (lees meer) vragen wij je het plaatje te uploaden bij imgur.com of imageshack.us."

En als je heel erg goed bent kan je gebruikers ook "curaten". Bijvoorbeeld: pas na 20 posts en minimaal 1 week lidmaatschap kan men plaatjes posten die buiten de whitelist vallen. Ik vermoed dat je spammers/hackers/etc. al binnen een week weet te achterhalen, zeker als ze 20 posts (reacties) moeten plaatsen.

Genoeg oplossingen hoor, de 1 kost alleen wat meer tijd dan de ander.

Ik zou tegen link-scan acties adviseren, veel te zwaar voor client en/of server. Funest voor performance.