En opsang vedrørende sikkerheden i Saldi

[nielsrune]

I bliver altså nødt til snart at tage sikkerheden mere seriøst i jeres kode.

I har lige introduceret en injectionmulighed, der er endnu værre end den, der blev introduceret i 2013, og som jeg i efteråret har informeret Claus om direkte på mail.

Nogle eksempler:

Opbevaring af koder

Den 29. oktober 2013 blev der i tråden viewtopic.php?f=5&t=923 gjort opmærksom på problemet i, at I lader alle passwords gemme som md5-hashes.

Den 11. november 2013 blev anvist en mulighed for, hvordan man kunne højne sikkerheden omkring opbevaring af passwords.

Intet skete.

I september 2014 lagde jeg et pull request på github med implementering af den foreslåede løsning i koden, og I har siden blot kunnet skrive løsning af.

Men stadig intet er sket her pr. april 2015.

Hul i databaseudtræk

Januar 2013 reklamerer I i tråden viewtopic.php?f=17&t=897 for mulighden for databaseudtræk.

Problemet her er, at Saldi fuldstændig ukritisk udleverer alle de oplysninger fra databasen, man spørger om.

Det kunne jo f.eks. være et fuldt udtræk af tabellen over regnskabets brugere og deres passwords. At passwords ligger som md5-hashes er reelt ingen hindring.

Man kan altså let skaffe sig en anden brugers loginoplysnigner, og kan udgive dig for denne i Saldi.

Måske denne bruger også bruger samme kombination af brugernavn og password på sin webmail, facebook, netbank, nemid...

Det handler altså ikke kun om Saldi isoleret. I har et kæmpeansvar over for jeres brugere for, at deres passwords er ordentligt beskyttede; især når I introducerer alvorlige huller i koden efterfølgende.

Adgangskoder til ftp-servere mv. er et andet eksempel på oplysnigner, der nemt kan hentes ud fra regnskabet. Endda endnu lettere fordi disse oplysnigner ligger i klartekst. Så sparer hackeren 10 sekunder på at skulle slå en md5-hash op.

Ovenstående er slemt nok i sig selv, men det stopper ikke her.

Det er også muligt gennem funktionen databaseudtræk at injekte poster i regnskabsdatabasen. Det lykkedes mig som en test sidste efterår at oprette en ny bruger med eskalerede rettigheder.

At I i koden prøver at opfange sql-kommandoerne delete og update er utilstrækkeligt, når I samtidig glemmer at blokere for insert.

De ovenstående muligheder for at udnytte dette hul har jeg advaret Claus om i en e-mail i november 2014, uden at det er blevet forsøgt rettet.

Eksekvering af php-kode i labelprint

Nu april 2015 reklamerer I i tråden viewtopic.php?f=17&t=1159 for muligheden for labelprint for varer.

Blot ved at læse tråden og se koden efter er det tydeligt, at I tillader fuldstændig ukritisk eksekvering af php-kode fra bruger input.

Jeg har netop undersøgt på en nyinstallation, om problemet er af så stort omfang, som jeg frygtede, da jeg så indlægget i tråden. Og det er det.

I har reelt åbnet op for, at en hvilken som helst bruger kan få adgang til at opdatere, indsætte og slette ikke blot i et enkelt regnskabs database, men i saldis hoveddatabase. En hacker kan derved stjæle hele jeres kunderkartotek, ændre alle brugeres password, forhøje eller nedsætte antallet af købte posteringer mv. Kun fantasien sætter grænserne, fristes man desværre til at sige.

-o0o-

I bliver simpelthen nødt til at tage sikkerheden alvorligt og få læst op på gængse sikkerhedsprocedurer for php, sql mv. i stedet for at opfinde jeres egne hullede løsninger.

På forsiden af saldi.dk står bl.a, at "Dine data er sikret i et top moderne hostingcenter."
Jeg er ked af at skulle sige det, men lige nu er det bedre overensstemmende med sandheden at skrive "Dine data gemmes i et top moderne hostingcenter, men kan læses af alle og enhver".

Som en afsluttende disclaimer skal jeg naturligvis oplyse, at jeg på intet tidspunkt har opnået, forsøgt at opnå, eller haft til hensigt at opnå mig adgang til data, der ikke tilhører mig selv. Alt hvad jeg skriver ovenfor er undersøgt, afprøvet og bekræftet på min egen server og alene med til formålet opfundne "dummy"-data.
Jeg har ovenfor bevidst ikke skrevet præcis, hvordan hullerne kan udnyttes, og jeg agter ikke at gøre det.

Jeg har længe forsøgt at bidrage til at undgå eller lukke de sikkerhedsproblemer, der gør sig gældende i et system som Saldi, men jeg kan blot konstatere, at det ikke bliver taget seriøst eller prioriteret fra udviklernes side. Og det er en skam, for I risikerer at kunderne flygter væk fra den hostede løsning, som I tjener jeres penge på.

[ht]

Hmm... Jeg er helt enig saldi er IKKE i top hvad det angår, der er også er del system kald til cmd programer som også gør det svært at køre i "chroot" miljøer f.eks. openbsd
f.eks. til pdf/print del. Og /temp burde ikke ligge åben på roden heller
se : https://ssl.saldi.dk/finans/temp/online.log

[Peter Rude]

Tak for ovenstående indlæg.
Af årsager som jeg jeg ikke endnu kender er jeg først nu blevet opmærksom på dette indlæg.
Jeg er enig i at labelprint funktionen ikke skulle have været implementeret og har sat den ud af drift indtil der er fundet en bedre løsning.
Der er blokeret for insert i query funktionen og der er ikke længere muligt at hente fra brugertabellen.
Jeg vil gerne takke for at der gøres opmærksom på sikkerhedsproblemer og vil sætte stor pris på hvis jeg fremover får en personlig besked, når det drejer sig om noget så vigtigt.
Min hverdag er meget ophængt og det kan gå lang tid mellem jeg selv læser i dette forum og de som har til opgave at reagere på indlæg, har ikke reageret.
Jeg har logs over alt hvad det siden implementeringen er skrevet i til labelprint og skriver nu en rutine som gennemsøger disse så jeg ved om nogen har udnyttet muligheden og vil så gøre hvad der er nødvendigt.
Mht, salt / hash vil jeg sørge for at det bliver implementerer snarest.

[blackbird1000]

Kan godt følge dig. Det er ligesom produktet saldi ikke er så vigtigt mere. Eller der ikke er styr på noget på grund af manglende ressourcer.

Har fået revisor på, han mener også det kan være tid til et skift, selv om løsning så ikke bliver lige så billigt.
Mening med saldi, er vel at ud over at det er billigt, har alle muligheder samt er fleksibel.
Men netop dette betyder at der er mange som bruger det, som ikke er særlig regnskabskyndig, herunder undertegnede.
Derfor skal det også være nemt, eller så skal der være gode manualer og forklaringer.

Dette sker ikke, som eksempel denne tråd jeg linker til,. I stedet for at en gang for alle at en halv time, på en ordentligt forklaring., som efterspørges af flere bruger. Så skal der flere opkald til. Hvis jeg ringer, får jeg sikkert hjælp, men det er jo ikke på denne måde de skal løse. Det kræver alt for meget tid.
Og tit har man glemt de forklaringer men fik efter et halv år, også skal man ringe og spildes begge parters tid igen.

Så saldi kan ikke kalde sig for en professionel løsning, før der bliver mere styr på dokumentationen. Også over de fejl mangler der , samt mulighed for tilretning. osv. Undskyldningen med at det ikke er tid til dette, holder ikke. Kun hvis man mener at færre kunder i butikken, betyder der skal bruges mindre support til kunder. En god dokumentation vil betyde at mange support opkald ikke kommer, heller hurtigt kan henvises til et beskrivelse.
Ville meget gerne hjælpe med dette, men er som sagt nok mere i den anden ende.

Et andet eksempel er, at jeg fandt en fejl i Import / Export, da jeg skulle flytte et regnskab. Det var noget med navne på feltet, og det blev løst ved et opkald., Men det burde i stedet være rapporteret som en fejl, her i forum og løsning også skrevet ind, så andre kan bruge det. Samt også mig selv. Kan ikke huske helt hvad problemet og fejlen var.