Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Lars J. Aas
@larsjaas
wow, sidney tilta jo helt i kveld...
Rune Jacobsen
@havremunken
Jeg så det da, men fikk ikke gjort noe med det selv pga. tidlig seng, så varslet på messenger-gruppa for mods. Prøvde å roe ham ned men tror ikke han ble imponert, og hadde da ikke tid til å lese gjennom hele tråden. Men ja, full tilt. Og sikkert godt for RUSK-bruken. ;)
Lars J. Aas
@larsjaas
// ==UserScript==
// @name         Strip Eurosport
// @namespace    http://*.eurosport.no/
// @version      0.1
// @description  remove stupid shit from eurosport.no
// @author       You
// @match        https://*.eurosport.no/*
// ==/UserScript==

(function() {
    'use strict';
    document.getElementById('etb-watchbar').outerHTML = "";
    document.getElementById('nav_category').outerHTML = "";
})();
Rune Jacobsen
@havremunken
Jeg er så og si aldri innpå der, men ble nysgjerrig og får ta en titt. :D
Fikk dette på epost nå, kan sikkert bli et fruktbart samarbeid!
image.png
Lars J. Aas
@larsjaas
du må svare med at du trenger penger for å krysspromptere mot en så eksklusiv brukergruppe som RUSK-brukerene, og du ser frem til de tar kontakt for å forhandle om summene...
Eurosport.no er jo en website som bruker 50% av skjermhøyden på ubrukelige, fixed/floating headere, som MÅ bort for å gjøre siten besøkbar.
Skjønner overhodet ikke IT/business-ansvarlige for sånne nettsteder.
Mustrum Ridcully
@kripos
Her kommer jeg med mine plebei-spørsmål og roter i den fine kode-diskusjonen dere voksne har her, akk ja.
Finnes det mulighet for at du Orion kan sjekke aktiviteten på forumet?Jeg vet ikke vilke admin-tools dere har tilgjengelige men jeg mener da altså at det er mistenkelig mange pålogget akkurat nå, over 700 nå nettopp, nå har det sunket til 678
nå er det 187, det er definitivt noe som ikke stemmer her
ikke faen at 500 logga seg av og på på fem minutter, det mener nå jeg da. Kan det være bots? og hvorfor?
Rune Jacobsen
@havremunken
Det er nok bots av noe slag, først og fremst for indeksering har jeg alltid antatt.
Det finnes ingen fornuftig grunn for den mengden besøkende på en fredagskveld uten kamp eller trenersparking. ;)
Jeg kan dessverre ikke se noe mer enn andre der, bare den statistikken nederst på frontsiden. Hadde vært interessant om det var én hissig bot som indekserte masse tråder samtidig for å komme opp med det perfekte AI/machine learning-baserte spam-innlegget. :D
@larsjaas Enig, og jeg sitter på en 4K skjerm og skjønner ikke hvordan de kan sløse sånn med screen real estate. Greit at Dezign (tm) krevet litt luft og sånt, men det har jo tatt helt av. Jeg får klaus bare av 2-3 cm med "elsk cookiene våre!"-bortkastet plass.
Lars J. Aas
@larsjaas
Koble denne til RUSK kanskje? https://dependabot.com/ Er jo ikke usannsynlig at RUSK-developer-gleden kan komme tilbake i f.eks. juleferien...
Rune Jacobsen
@havremunken
Ja, har sett litt på den tidligere (andre prosjekter) og det er ikke så dumt å få litt hjelp med å holde sikkerhetsproblemene på avstand. :)
Har hatt litt lyst til å se på indexeddb for en annen ting også, så skal ikke se bort fra at motivasjonen kommer krypende tilbake, nei.. :D
Lars J. Aas
@larsjaas
Siden vi har ca 100 brukere så lurer jeg på om vi bare skal externalize lagring avstore data mot bår egen cloud-server-sidecar. Betinger at RUSK vet brukerid da, så login og lagre brukerid lokalt for når man er utlogget kanskje?
Kan ikke bli mange megabytes med data, i alle fall om server kjenner datastrukturen.
min cloudserver er i alle fall lite brukt, så ingen kapasitetsproblemer å kjøre det på den i alle fall.
Rune Jacobsen
@havremunken
Tipper det kanskje er like greit ja - så litt på "brukerautentisering" i forrige runde, og det eneste vi vel må passe på er at vi ikke tilgjengeliggjør noen APIer som snoker kan benytte for å komme med giftig data.
Har tenkt at en måte å håndtere det på er noe ala JWT, hvor RUSK gir brukernavn til server side API, som sender en PM på RBKweb, som RUSK henter ut en autentiseringskode fra.
Lars J. Aas
@larsjaas
høres for komplisert ut
Rune Jacobsen
@havremunken
Forsåvidt ikke uenig, men mtp. vi er open source - hvordan kan vi ellers beskytte APIet?
Folk kan jo lett se URLene som blir kalt opp.
Lars J. Aas
@larsjaas
Hmm, vanskelig problem. Vi får til at en RUSK-bruker logger inn på rbkweb og browser Garderoben og har en kode i brukernavnet som RUSK kan snappe opp via å se på Garderoben-indeksen (som forøvrig alle vil kunne se dog). Om 2mas tillater en sånn bot-bruker da. Kan noe sånt brukes til noe?
Blir jo dessverre ikke 100% bruker-unikt, men du kan i alle fall se at en request kommer fra en innlogget bruker.
Tror uansett man må lagre unna en AES-nøkkel lokalt i RUSK hos brukeren, så vil problemet være å få gitt den nøkkelen trygt til en klient som man har verifisert at er en gitt bruker.
Lars J. Aas
@larsjaas
Hva om RUSK tar kontakt med sidecar, får beskjed om å PMe RUSKbot med kode "pizza123", i bakgrunnen PMes RUSKbot, og bing bang boom så har vi ID på hvem som sendte oss koden.
Rune Jacobsen
@havremunken
Jeg har allerede en sånn RUSK-bruker som sikkert kunne vært brukt, ikke snakket med 2mas om det. Men nå nærmer vi oss veldig mitt opprinnelige forslag. ;)
Rune Jacobsen
@havremunken

Jeg kom for min del frem til følgende som relativt sikkert og enklere enn mye annet:

  1. Bruker sier til RUSK "Du, jeg vil gjerne benytte meg av sidecar-funksjonaliteten" på ett eller annet vis, muligens menyen på venstre side som jeg må få stabilisert litt ser jeg.

  2. RUSK kaller, eksempelvis for meg, opp noe ala https://sidecar.com/api/rusk/enableuser/OrionPax

  3. Dette fører til at sidecar gjør kun to POST oppslag mot RBKweb - en for å logge inn, en for å poste en PM som inneholder en hemmelig kode. Ok, tre da, så får den logget ut igjen.

  4. Når dette er gjort, svarer sidecar på requesten fra pkt. 2.

  5. RUSK hopper til innboks, lokaliserer PM fra RUSK-brukeren (som sidecar poster som), og henter ut AES-nøkkel, ev. en token som kan brukes for å hente den endelige nøkkelen fra sidecar API om vi vil gjøre det komplisert. Hvis sistnevnte, gjør api-kall til sidecar, motta endelig nøkkel, lagre den.

  6. RUSK sletter meldingen fra innboks. Fra og med nå har RUSK på denne datamaskinen en autentiseringsnøkkel som forteller sidecar at den er autentisert for å opptre som den navngitte brukeren.

Grunnen til at jeg tenker dette er enklere er at da er det kun RUSK som trenger å parse innboks på RBKweb (og denslags er jo noe av det som er lett der) - vi slipper å skrive noe polling-funksjonalitet for sidecar som skal inn der, den trenger kun å poste utgående meldinger, som jeg vil tro er mye enklere.
Jeg har ikke tenkt på dette i timesvis, men det slår meg som relativt sikkert; Hvis en slem bruker ser på kildekoden til RUSK vil han maks oppnå at brukeren han prøver å svindle får en PM som de ikke skjønner mye av.
Hvis vi i pkt. 5 sender PM med token som så må leveres til sidecar sammen med brukernavnet den gjelder innen f.eks. 1-2 minutter for å være gyldig, blir det relativt lite rom for å brute force ting også.
Pluss at "token" kan jo være ganske lang og uregjerlig for å gjøre det ekstremt vanskelig å forsøke å lure tjenesten.
Lars J. Aas
@larsjaas
Sånn jeg tenkte, så ville jeg ha enklest mulig kode i RUSK så vi slipper å deploye stadig nye versjoner med bugfixer der, samt at vi unngår at vi unødig legger rask i innboksen til RUSK-brukere som de kanskje ikke skjønner bæra av. I tillegg vil vi ikke trenge å gjette på brukerid/navn eller stole på noe som kommer fra brukerene da det vil være avsender av PM som er brukeren.
Rune Jacobsen
@havremunken
Forsåvidt enig i at enkel kode i RUSK er fint, men det er trivielt å slette PM etter at vi har lest ut nødvendige ting av den. Og brukernavnet har vi jo allerede lest ut fra RBKweb-siden, siden det nødvendigvis må være et krav at man er logget inn for å kjøre en autentisering.
Lars J. Aas
@larsjaas
race conditions, exceptions og drit kan gjøre at inbox-meldinger ikke slettes. stoler mer på at vi klarer å sende en one-off melding enn å ta imot, tolke og så slette meldingen. og at vi slipper å stole på RUSK (om man tenker sikkerhet i forhold til angrepsvektorer) i forhold til å gjøre identifiseringen.
Rune Jacobsen
@havremunken

Å sende/ta imot via http har jeg gjort via C# for flere år siden ifm. med en test for noe STAut-greier som aldri ble noe av, det er kun et par http posts som sagt. "Min" måte ville jo ikke sende noe via PM, den sender til sidecar via et API-oppslag, som trigger post av en PM. Innholdet i denne PMen bør være trivielt å finne igjen, og vi kan jo sette markører i selve innholdet i meldingen som gjør den lettere å finne, samt legge ved tekst som sier til brukere "Dette er en melding brukt av RUSK for å verifisere deg som bruker, sorry at vi ikke klarte å slette den automatisk", det er ikke noen kris. Og, viktigst, da er det ikke RUSK som gjør autentisering/identifisering - det er RBKweb selv. Vi parser allerede brukernavnet ut i en av modulene; Hvis noen skulle være onde nok til enten å tukle med sideinnholdet (forandre brukernavnet sitt i DOM) eller manuelt kalle APIet, vil det føre til at brukeren som forsøkes svindlet får en PM de ikke burde hatt. Den kan jo også til og med innehole en "Klikk her hvis du ikke har forsøkt å autentisere deg"-link som gjør at IP-adressen som ble brukt for det opprinnelige API-kallet blir logget som mistenkelig.

Når det gjelder race conditions - hvis det opprinnelige "autentiser meg"-API-kallet først returnerer når sidecar har sendt PM, skal det vel litt til at meldingen ikke er i inbox når RUSK går dit. Men igjen, det er jo enkelt å gjøre denne meldingen slik at det ikke er noen krise, i verste fall en enkel retry. Hvis vi lager et overlay + noen variabler som gjør at RUSK "tar over" UI med mer overlay på påfølgende sider, er vel det eneste vi trenger å bekymre oss for at bruker trykker f5 midt i en prosess f.eks. Jeg tror ikke det trenger å være noe stort problem heller, så lenge vi lagrer hvor vi er i prosessen f.eks. i localStorage, wizard style, så RUSK under oppstart kan lese dette og vurdere om den burde ta over showet. Inkluder en enkel teller på feilsituasjoner som gjør at den avbryter etter noen forsøk, så nærmer det seg infanterisikkert.

Lars J. Aas
@larsjaas
Syns heller ikke RUSK skal rote igjenmom innboksen til brukerene - sånt sett er å sende en melding mye «renere».
Brukere kan lukke browsere på uventede tidspunkt. Dette er en transaksjon som bør være så atomisk og ryddig som mulig.
Rune Jacobsen
@havremunken
Men det er jo ikke noe problem hvis vi lagrer progress i localStorage. Ta med et tidspunkt, så kan den rydde opp etter seg og varsle brukeren om at autentiseringsforsøket ble avbrutt pga. brukerhandling. Og jeg ser det ikke som "roting" i innboksen at den åpner én melding, i praksis sendt til seg selv, eksplisitt på brukerens forespørsel, for å få tilgang til utvidet funksjonalitet. Det er en kjapp og enkel handling som sikrer oss at det er den innloggede brukeren som ber om å få en nøkkel til sidecar-APIer. Med tanke på hvor lite APIer som eksisterer i phpBB ser jeg ikke mange andre muligheter som kommer med vesentlig færre nedsider.
Lars J. Aas
@larsjaas
Skjønner ikke argumentasjonen din. Du vil løse kompleksiteten i meldingsutvekslingen med ennå mere kompleksitet. i stedenfor at vi har en lett overvåkbar komponent som vi deployer i eget tempo og stenger ned om det er baluba så vil du spre potensielle balubakilder til 100+ brukere hvor vi har null kontroll på deployment/oppgraderinger.
Rune Jacobsen
@havremunken

Det blir litt mer kompleksitet i RUSK for å unngå mye mer kompleksitet server side. RUSK kjører i en browser og har tilgang til DOM-parsing som stort sett er det den gjør. Skal vi begynne å interface med RBKweb server side så må vi inn med biblioteker for å parse HTML og simulere det samme. Samme potensielle race conditions eksisterer der, hvis f.eks. flere brukere prøver å autentisere seg samtidig. Jeg er ikke enig i at dette er spesielt komplekst på RUSK-siden, og hvis vi er redde for det er det da bare å ha et status endpoint på sidecar hvor vi kan si "Autentisering funker ikke nå" som gjør at man skrur av hele funksjonaliteten på RUSK-siden.

Det er ikke viktig for meg om det går ene eller andre veien, men den opprinnelige tanken var at ved å autentisere ved å sende PM fra sidecar gjennom RBKweb til brukeren, så kan sidecar-integrasjonen være meget simpel (3 http(s) kall), mens det å lese en kode fra innboksen er forholdsvis trivielt sammenlignet med andre ting vi har gjort. Den eneste autentiseringsmekanismen vi har å forholde oss til er RBKweb selv, og hvis vi får en melding til eller fra brukeren så handler det kun om å parse ut en kode. Å lese en melding for å hente ut en access token er lett i RUSK, det er jo simpel DOM-querying og en regex.

Poenget mitt er altså bare; Skal vi være sikre på at brukeren er den han sier han er, bør det være en PM utekslet på RBKweb. Om den går fra RUSK til sidecar eller omvendt er uvesentlig, jeg ser det bare som mindre arbeid at denne meldingen går fra sidecar (fåtall kall til webserver) til RUSK (allerede istand til å lese DOM og dermed hente ut tilgangskode).

Jeg tror dette kunne funke helt fint uten veldig mye mer kode noe sted, mens localStorage-tingene kun var for å legge til et lag med sikring, gjøre prosessen mulig å avbryte både av bruker og fra server side o.l.
Rune Jacobsen
@havremunken
Man kan også se utgående meldings-id når man sender en melding (ved litt parsing av html), så det vil være mulig å directe RUSK rett til meldingen når den er sendt. Uproblematisk.