Veiligheidsfout treft Ruby on Rails

De ontwikkelaars van Ruby on Rails hebben bekendgemaakt dat er een flink veiligheidsprobleem aanwezig is in vrijwel alle versies sinds 1.0 van het opensourceframework voor webapplicaties. Alle ontwikkelaars die applicaties maken op basis van Ruby on Rails worden dan ook sterk aangeraden om de nieuwste versie 1.1.6 te gaan gebruiken.

Door de fout in Ruby on Rails is het mogelijk om een webapplicatie via specifieke urls te blokkeren of zelfs gegevens te verwijderen van de server. Aangezien alle recente Ruby on Rails-versies tot en met 1.1.5 door de fout zijn getroffen is het probleem tamelijk ernstig. In versie 1.1.5, die eerder deze week werd uitgebracht als mogelijke oplossing voor het probleem, is een gedeeltelijke oplossing voor het probleem geïmplementeerd maar die bleek niet afdoende te zijn, zodat dus ook gebruikers van deze versie moeten upgraden. Het upgraden van Ruby on Rails-applicaties die nog gebruik maken van oudere versies kan compatibiliteitsproblemen veroorzaken. Wanneer het niet mogelijk is om te upgraden, adviseren de ontwikkelaars van Ruby on Rails om url-blokkeringen toe te voegen aan hun applicaties om het probleem gedeeltelijk te omzeilen. Voor versies van Ruby on Rails sinds 1.1.0 zijn er inmiddels ook patches ter beschikking gesteld door het project die echter handmatig moeten worden geïnstalleerd.

Ruby on Rails is een framework voor het ontwikkelen van webapplicaties die gebruik maken van een databasebackend. Het framework maakt gebruik van de scripttaal Ruby en heeft als motto 'don't repeat yourself'. Dit houdt in de praktijk in dat de ontwikkelaar weinig triviale code hoeft te schrijven en zich kan richten op de kern van de applicatie.

Reacties (21)

[TheBlasphemer]

Oei! flinke klap voor ruby on rails!
Is natuurlijk nog steeds een beetje een taaltje dat zich moet bewijzen, en zo'n lek lijkt me niet echt vertrouwen uitstralen

[The - DDD]

Taaltje? Framework zul je bedoelen.

Ruby is een scripting taal die in 1995 aan de wereld werd getoond. Ruby on Rails daarentegen is pas van 2004.

Vaak hoor je over Ruby on Rails dat het nog niet volwassen genoeg is en nog te nieuw is. Dit incident is daar een prima voorbeeld van. Hoewel het met ieder framework kan gebeuren natuurlijk. Maar daar kun je in een wellus nietus discussie lekker aan voorbij gaan.

Ruby on Rails is overigens een erg leuk framework. Mits je binnen de grenzen en mogenlijkheden van het framework blijft. Kom je er buiten, wat in applicaties die iets meer dan dataentry inhouden al snel gebeurt, dan valt het voordeel van Ruby on Rails in mijn ogen volledig weg.

[Verwijderd]

Ruby on Rails,

Ik dacht gelijk aan een andere Ruby

ATI Ruby

[onox]

Dan heb ik liever Ruby on Bed

[cybero]

Ruby on Rails was toch juist bestand tegen dit soort aanvallen. Het had juist zo'n veilig imago waar je niet alles zelf hoefde dicht te zetten tegen injections enzo.. Enfin. Bugs zijn er altijd natuurlijk..

[- peter -]

Voor zover ik weet moet je ook bij RoR je code handmatig deels beveiligen tegen injections.

[The - DDD]

Standaard Active Record (RoR's data access component) doet in de standaard gevallen alle SQL escaping die nodig is.

Wil je echter wat meer cstom zaken doen, zoals eigen condities aan queries toevoegen die niet via Active Record te doen zijn, dan moet je inderdaad opletten.

Vooral de find methode van Active Record model objecten zijn gevoelig, want alles wat je daar aan meegeeft wordt letterlijk in een SQL query geplant.

Users.find(:all, :conditions => "name = like '%#{session[:user].name}%'")

Om dat te voorkomen moet je gewoon data binding gebruiken:

Users.find(:all, :conditions => "name = like ?", session[:user].name)

Raar maar waar, dit kleine verschil in code voorkomt al heel wat SQL injection ge-eikel in RoR.

[flowerp]

Users.find(:all, :conditions => "name = like ?", session[:user].name)

Raar maar waar, dit kleine verschil in code voorkomt al heel wat SQL injection ge-eikel in RoR.

Idd, in normale gevallen gebruik je dus ALTIJD de laatste versie. De eerdere versie zou je alleen gebruiken als je iets doet dat niet met een binding is uit te drukken, bijvoorbeeld als je 'name' dynamisch wilt doorgeven.

Het onderstaande kan volgens mij niet:

Users.find(:all, :conditions => "? = like ?", session[:user].nameStr , session[:user].name)

Maar de situaties waarin dit nodig is, zijn erg klein.

[J.J.J. Bokma]

"
Raar maar waar, dit kleine verschil in code voorkomt al heel wat SQL injection ge-eikel in RoR."

Ook in Perl, en nooit begrepen waarom dit in eerste instantie ook niet in PHP zat, maar alles met magicgekloot moest.

[flowerp]

Ook in Perl, en nooit begrepen waarom dit in eerste instantie ook niet in PHP zat, maar alles met magicgekloot moest.

In Java werkt het trouwens ook zo (prepared statements). De DB en/of driver zorgt dan voor de DB specificieke escaping zodat het altijd klopt. Daarom hebben Java web apps ook nooit last van SQL injection. (tenzij de Java 'programmeur' natuurlijk een voormalig PHP scripter was en op de PHP manier te werk gaat.)

ASP.NET gebruikt ook het zelfde mechanisme. Eigenlijk is alleen PHP een beetje de dwarsligger en dacht het 'simpel' aan te pakken, maar simpel wordt uiteindelijk toch moeilijk als het betekent dat je gewoon je kop in het zand stopt voor bepaalde dingen.

[Verwijderd]

Alles wat nauwelijks gebruikt wordt heeft een veilig imago.

[Bigs]

Mwa dat zegt niet zo veel.. daarvoor heeft PHP ook magic_quotes. Met Rails gaan die beveiligingen zelfs minder transparant dan bij PHP, waardoor onervaren gebruikers zeer makkelijk grote beveiligingslekken kunnen creëren.

[onox]

Als ik me niet vergis gaan magic_quotes en safemode eruit bij vanaf versie 6. magic_quotes_gpc is mijns inziens toch al een ruk instelling. Al je super globals worden geescaped.

[J.J.J. Bokma]

"daarvoor heeft PHP ook magic_quotes."

Ja, en de ontwikkelaar die dat er in gestopt heeft mag van mij nooit meer software maken. Wat een prutser.

Elke andere fatsoenlijke taal (IMO) kan variabelen binden: Perl, Java, etc.

[flowerp]

Wat een prutser.

Wat dit punt betreft is PHP dan ook een variant op het motto: "voor programmeurs door programmeurs", namelijk "voor prutsers, door prutsers".

[eamelink]

Ach, nu is het voordeel dat het framework los van de individuele applicaties geinstalleerd kan worden.

Dus als je op een server 20 railsapps hebt draaien, hoef je alleen één keer het framework de updaten, en je loopt weer bij.

Als kan dat in de praktijk natuurlijk toch weer wat problemen geven omdat 1.0 niet compatibel is met 1.1

[The - DDD]

Ja en nee. Je zult bij een dergelijke upgrade toch wel wat meer voorbereiding en validatie willen doen voordat je zo even een nieuwe versie van een framework ergens onder gooit.

[_JGC_]

Dat is dan weer het voordeel van opensource software: de patch die is vrijgegeven kan je proberen te backporten naar 1.0, of er is iemand anders al zo slim geweest om dat voor je te doen. Je hebt hiermee niet afhankelijk van de software ontwikkelaars.
Bovenstaande wordt voornamelijk door linux distributies toegepast, vaak zijn er dan ook gefixte versies binnen een distributie die nog niet eens bij de auteur van het stukje software te krijgen zijn.

[Verwijderd]

En dan loop je ook gelijk tegen een groot nadeel van Open Source software aan; die persoon die de patch in elkaar gezet heeft is onbekend en potentieel kwaadwillend, dus zal je de patches vantevoren goed moeten testen. Als de bron het project is, en het project heeft een strikt proces voor het accepteren van patches is het gelukkig al een stuk veiliger.

[smesjz]

".....you can trigger the evaluation of Ruby code through the URL because of a bug in the routing code of Rails."

Dit heeft dus niks te maken met Active Record o.i.d. of met het programmeren van je applicatie zelf.

De routing code werkt als een dispatcher die op basis van de URL de juiste scripts laadt. In de URL wordt bijv. de naam van de controller en action meegegeven:

map.connect ':controller/:action/:id'

Het is gewoon een bug in de core van het framework. Update was snel beschikbaar en hier ging de update zonder problemen.