SQL Injecties, gewoon je rechten aanpassen?

Door Toppe op maandag 5 december 2011 07:24 - Reacties (33)
Categorie: Invenstory, Views: 8.210

Zat ik vanochtend even op PFZ.nl kom ik via een erg grote omweg de pagina tegen om sql injecties tegen te gaan.

Het volledige artikel kunnen jullie hier vinden maar ik zal ook even een stuk kopiëren:
Door de juiste databaserollen aan te maken, bepaal jij wat een bepaalde rol wel of niet mag doen. Wanneer een rol geen DELETE mag uitvoeren in een tabel of geen SELECT mag uitvoeren op een andere tabel, dan zal dit ook echt niet lukken. Kun je nog zoveel SQL injection op los laten, dat gaat gewoon niet werken.
Ik vind dit raar. Verder op in het artikel staat dat je ook met prepared-statments kan gaan werken etc, maar toch vind ik dit gewoon raar.

Veelal mensen met een kant en klare webhosting, kunnen geen rechten aanpassen op hun database, laat staan dat mensen weten hoe het moet.

Daarbij wil ik dat mijn database de standaard rechten heeft, als ik een tabel wil droppen kan dat niet, omdat ik daar geen rechten voor heb. Het is dus vrijwel gewoon één richtingsverkeer.

Wat is jullie mensen over het aanpassen van de rechten om sql injecties tegen te gaan?


Of welk script/class gebruiken jullie het liefst om sql injecties tegen te gaan?

Voor de geïnteresseerde: Eerste afbeeldingen Invenstory online

Volgende: Home Domotica 04-'15 Home Domotica
Volgende: Invenstory -> Verhuizen 11-'11 Invenstory -> Verhuizen

Reacties


Door Tweakers user nIghtorius, maandag 5 december 2011 07:37

De truuk is dat je met meerdere users je (My)SQL database benaderd.. bijvoorbeeld voor functies waarbij alleen een record aangemaakt kan worden dat er een SQL user gebruikt wordt die alleen records kan aanmaken en niet verwijderen.

als je een table verwijderen moet of een record verwijderen moet dan zorg je ervoor dat je een sql user gebruikt die deze rechten heeft. ( deze zit dan vaak in een gebied van je website waarbij b.v. een " beheerder " alleen toegang tot heeft )

Door Tweakers user cytherea, maandag 5 december 2011 07:45

Beetje vreemd is het inderdaad wel, de meeste SQL injections worden gebruikt om data niet-legitiem uit te lezen en een SELECT is vaak het minste wat een rol/user kan. Dus dan zit je nog steeds met een probleem. Het kan wel een oplossing zijn voor een wijziging in je schema oid.
Maar dan nog moet je elke variabele die je via de browser binnenkrijgt (eigenlijk uit elke bron) behandelen als gevaarlijk en onbetrouwbaar en filteren op wat jij denkt dat er inzit. Dus een id mag alleen getallen bevatten en de rest eruit slopen en dat in je query gebruiken met de goeie escaping. Dat in combinatie met alleen de rechten die noodzakelijk zijn maakt een systeem redelijk waterdicht.

ps. Misschien moet je je stuk nog eens nalezen, er zitten zinnen in die niet helemaal lekker lopen. "maar toch ik dit gewoon raar." bijvoorbeeld.

Door Tweakers user jbdeiman, maandag 5 december 2011 08:09

Alleen de rollen goed zetten helpt zoals Cytherea al aangeeft helemaal niet in de meeste gevallen. Wanneer iemand je website kan zien, heeft hij/ zij, vanuit de webapplicatie al de rol waarmee gelezen kan worden.
Is het alleen een leesrol? Vaak wel, maar dat wil niet zeggen dat je er meer data uit kan krijgen dan mogelijk is. Zo kan je dan keurig een "SHOW TABLES" query erheen gooien, en misschien aan de hand van de data die je terugkrijgt allemaal query's op verschillende tabellen uitvoeren.
Zo kan je achter gebruikersgegevens e.d. komen, en dat met alleen Leesrechten.

Rollen zijn geen oplossing tegen SQL injectie, gebruikersinvoer moet je gewoon nooit vertrouwen en altijd controleren voordat je het in een query stopt. Rollen zijn een oplossing voor problemen die ontstaan omdat iemand niet alleen selectie, maar ook bewerk en verwijderrechten heeft. Dit kan via SQL injectie zijn, maar ook omdat iemand per ongeluk rechten heeft op bepaalde delen van de website waarin gegevens gewist worden.

Het goed definiëren van Rollen is nooit verkeerd, maar biedt in deze nooit een complete oplossing.

Door Tweakers user ACM, maandag 5 december 2011 08:21

Volgens mij is het best wel inefficient om steeds nieuwe verbindingen te moeten maken om bepaalde queries uit te kunnen voeren. Bovendien is het funest voor de werking van transacties.

Al met al zou het best veiliger kunnen worden met rollen instellen, maar moet je wel heel erg oppassen dat je jezelf als programmeur niet te veel extra werk op de hals haalt om alles in goede banen te leiden en bovendien dat je niet in allerlei dataveiligheidsvalkuilen stapt.

In theorie moet je vooral rekening houden met mislukkende statements door constraints, dat invoer ook je complete query kan veranderen is "bijzaak".

Ik zou zelf in ieder geval als eerste advies "altijd alle gebruikersinvoer valideren, ook als ie het niet zelf in zou moeten typen (alles uit GET, POST en Cookie dus)" en als tweede "en je kan dat deels doen door met prepared of geparametriseerde statements" te werken.

[Reactie gewijzigd op maandag 5 december 2011 08:22]


Door Tweakers user Rushleader, maandag 5 december 2011 08:56

ACM heeft een goed punt. Zoveel mogelijk controleren d.m.v. reguliere expressies en werken met een variant van mysql_escape_string (als je met php werkt) . Daarmee kan je bijna alles afvangen.

Door Tweakers user RobIII, maandag 5 december 2011 09:19

Rushleader schreef op maandag 05 december 2011 @ 08:56:
Zoveel mogelijk controleren d.m.v. reguliere expressies
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. — Jamie Zawinski
Reguliere expressies pas je gewoon toe waar nodig. Soms voldoet een simpele "intval" (of whatever functie PHP daarvoor heeft) of "filter_var('bob@example.com', FILTER_VALIDATE_EMAIL)" enz. al.

Wat wél aan te raden is is minimaal 1 gebruiker waaronder de (web)applicatie draait die niet eens toegang heeft tot een x-aantal tabellen waar, voor die applicatie, toch niets te beleven is. En die bijv. geen drop/alter-table rechten heeft. Ik ben 't er mee eens dat een aantal gebruikers met verschillende rechten voor 1 (web)applicatie voor verwarring (lees: groter risico) kan zorgen. Maar een specifieke cron-user met wat extra rechten voor bijvoorbeeld maintenance-taken is helemaal zo gek niet.

Onlangs postte ik dit nog (waar parameterized queries buiten beschouwing gelaten zijn, maar die ik wél aanraad).

[Reactie gewijzigd op maandag 5 december 2011 10:00]


Door Tweakers user Patriot, maandag 5 december 2011 09:20

Het kan nooit kwaad om mensen na te laten denken over de rechten die ze geven aan de user waarmee ze de database benaderen. Om het dan in te delen in back-end/front-end kan ik me ook nog wel voorstellen, maar verder dan dat wil je imo niet gaan.

Verder vind ik het niet gek dat ze het in het artikel noemen. Het feit dat er mensen zijn die de rechten niet in kunnen stellen mag geen argument zijn om het er niet in op te nemen in ieder geval.

Het feit dat ze ermee beginnen in hun artikel, is denk ik een beetje vanuit een 'beginnen bij de basis' principe.

EDIT:
Overigens wel grappig om te zien dat PHPFreakz nog bestaat. Ik kwam er zelf eigenlijk nooit, maar heb zelf wel een aantal jaren op een webmastercommunity rondgelopen en daar hoorde ik er nog wel eens wat over.

[Reactie gewijzigd op maandag 5 december 2011 09:53]


Door Tweakers user YopY, maandag 5 december 2011 09:33

Tabellen droppen of tabelstructuren aanpassen hoeft je applicatie in 99.9% van de gevallen niet te doen, buiten de eerste installatie of upgrades om. Geef je applicatie slechts de toegang die het nodig heeft, ipv de makkelijke 'grant all' oplossing die de meeste mensen nemen (en die zijn lui). Ten tweede, gebruik altijd prepared statements, er is absoluut geen reden om nog de archaïsche mysql_query en query-bouwen-met-string-concats te gebruiken. Ten derde, als je op shared hosting zit waar je geen volledige controle hebt over je database en de toegangsrechten van je databaseaccount moet je andere hosting zoeken - ik heb bijv. goedkope shared hosting (60 euro / jaar), maar daar zit wel cPanel bij waar je o.a. nieuwe databaseaccounts aan kunt maken èn toegangsrechten kunt instellen.

Door Tweakers user pim, maandag 5 december 2011 09:49

Rushleader schreef op maandag 05 december 2011 @ 08:56:
en werken met een variant van mysql_escape_string (als je met php werkt) . Daarmee kan je bijna alles afvangen.
Niks 'bijna'. Dit werkt met PHP 100% goed tegen mysql injectie.
De oplossing in een andere hoek zoeken is naar min idee vreemd en onzinnig..

Door Tweakers user Ram0n, maandag 5 december 2011 09:58

pim schreef op maandag 05 december 2011 @ 09:49:
[...]

Niks 'bijna'. Dit werkt met PHP 100% goed tegen mysql injectie.
De oplossing in een andere hoek zoeken is naar min idee vreemd en onzinnig..
Prepared Statements bevinden zich in een andere hoek, maar ik zou het vreemder vinden om mysql_escape_string te verkiezen boven PS's.

(uiteraard zijn er enkele gevallen waarbij Prepared Statements niet bruikbaar zijn, ik wil enkel aangeven dat mysql_escape_string niet de enige 'heilige graal' is)

[Reactie gewijzigd op maandag 5 december 2011 09:59]


Door Tweakers user Toppe, maandag 5 december 2011 09:58

YopY schreef op maandag 05 december 2011 @ 09:33:
Ten derde, als je op shared hosting zit waar je geen volledige controle hebt over je database en de toegangsrechten van je databaseaccount moet je andere hosting zoeken - ik heb bijv. goedkope shared hosting (60 euro / jaar), maar daar zit wel cPanel bij waar je o.a. nieuwe databaseaccounts aan kunt maken èn toegangsrechten kunt instellen.
Ben ik niet met je eens, als ik bij een provider zit ie me erg bevalt maar mij dus niet de optie geeft om de rechten aan te passen zou ik niet zomaar gaan verhuizen. Daarbij vermelden niet alle webhosters of je de rechten kan aanpassen van je databases.

Wat ik jammer vind is dat je bij ELKE verandering die je wilt maken altijd mysql_escape_string moet gebruiken. Wat ik mis is dat je niet $_POST = mysql_escape_string($_POST); kan gebruiken (Zal ik voor de zekerheid moeten testen,maar weet het zo goed als zeker).

Hiermee zou je alles kunnen afvangen qua post data. Als jij 25 regels in een tabel wilt opslaan moet je nu 25x mysql_escape_string invoeren.

PDO schijnt een stuk veiliger te zijn, maar ook hier weet ik niet of de $dbh->execute functie wel standaard mysql_escape_string heeft ingebouwd..? Heeft prepared statemens dus veiliger dan mysql_query OID

[Reactie gewijzigd op maandag 5 december 2011 10:01]


Door Tweakers user Ram0n, maandag 5 december 2011 10:02

Toppe schreef op maandag 05 december 2011 @ 09:58:
[...]
Wat ik jammer vind is dat je bij ELKE verandering die je wilt maken altijd mysql_escape_string moet gebruiken. Wat ik mis is dat je niet $_POST = mysql_escape_string($_POST); kan gebruiken (Zal ik voor de zekerheid moeten testen,maar weet het zo goed als zeker).

Hiermee zou je alles kunnen afvangen qua post data. Als jij 25 regels in een tabel wilt opslaan moet je nu 25x mysql_escape_string invoeren.
Dat kan natuurlijk eenvoudig met iets als het volgende:

PHP:
1
array_walk_recursive( $_POST, 'mysql_real_escape_string' );


Door Tweakers user Toppe, maandag 5 december 2011 10:06

hmz, kan natuurlijk ook.

Offtopic:
Mochten er mensen zijn die www.invenstory.eu proberen te bekijken maar welke moetsten inloggen, de problemen zouden nu opgelost zijn.

Door Tweakers user Cyphax, maandag 5 december 2011 10:15

Ik ben wel voorstander van de rechten op je database afstemmen op de rollen binnen de applicatie. Ik vind het ook een goed idee om databasebewerking in stored procedures te zetten en de databaseusers geen rechten te geven op tabellen maar te laten interacteren via die SP's.

Maar da's allemaal helemaal niet tegen SQL-injectie. Als je site of applicatie gevoelig is voor SQL-injectie, dan is het gewoon tijd om je databaselaag een keer goed onder handen te nemen.

Door Tweakers user Blokker_1999, maandag 5 december 2011 10:56

hmm, thema komt me bekend voor :P. Heb ik zelf ook al gebruikt.

Door Tweakers user Toppe, maandag 5 december 2011 11:04

Blokker_1999 schreef op maandag 05 december 2011 @ 10:56:
hmm, thema komt me bekend voor :P. Heb ik zelf ook al gebruikt.
Ergens van een gare japanse thema website weg gehaald, was het enigste wat er een beetje uitzag... Ik zal de link wel ff opzoeken...

Maar goed, je zegt niet wat je er van vind 8)7

[Reactie gewijzigd op maandag 5 december 2011 11:10]


Door Tweakers user RobIII, maandag 5 december 2011 11:19

N.v.m.

[Reactie gewijzigd op maandag 5 december 2011 11:19]


Door Tweakers user ACM, maandag 5 december 2011 11:35

Toppe schreef op maandag 05 december 2011 @ 09:58:
Wat ik jammer vind is dat je bij ELKE verandering die je wilt maken altijd mysql_escape_string moet gebruiken. Wat ik mis is dat je niet $_POST = mysql_escape_string($_POST); kan gebruiken (Zal ik voor de zekerheid moeten testen,maar weet het zo goed als zeker).
Je moet met dat soort algemene calls heel erg oppassen. Het kan zomaar zijn dat je sommige dingen helemaal niet in MySQL op gaat slaan of eerst bewerkt alvorens dat te doen. En vziw is er geen eenvoudige unescape van mysql_escape... Dus het is beter om het escapen dicht bij de query te houden, ook omdat je op die manier eenvoudige van database en/of opslagprocedure kan wisselen.

Het is inderdaad lastig dat je daardoor bij elke query weer moeite moet doen.

Door Tweakers user Ram0n, maandag 5 december 2011 12:00

ACM schreef op maandag 05 december 2011 @ 11:35:
[...]

Je moet met dat soort algemene calls heel erg oppassen. Het kan zomaar zijn dat je sommige dingen helemaal niet in MySQL op gaat slaan of eerst bewerkt alvorens dat te doen. En vziw is er geen eenvoudige unescape van mysql_escape... Dus het is beter om het escapen dicht bij de query te houden, ook omdat je op die manier eenvoudige van database en/of opslagprocedure kan wisselen.

Het is inderdaad lastig dat je daardoor bij elke query weer moeite moet doen.
Inderdaad, het komt bijvoorbeeld ook vaak voor dat je de data van het formulier zowel op de site wilt weergeven (ter bevestiging o.i.d.) als op wilt slaan in de database.

Door Tweakers user Toppe, maandag 5 december 2011 12:09

Maar, stuur je hem dan terug als ingevuld formulier of als blanke data?

Ik heb bijvoorbeeld na ELKE execute van PDO de volgende functie:


PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<?Php
    /* Dit is even een sneak-preview van mijn class
     * Het is geen kopie, maar ff snel getypt in de vroem vroem (Auto...)
     * 
     * Alles word dus afgewerkt met deze 2 classes en de bij behorende functies.
     * Zo kan ik later alles aanpassen wat ik zou willen
     * Zonder een heel script te verbouwen
     */
    class Base {
        //een hoop functies

        function Database(){
            $dbh = new PDO('mysql:host=xxx;port=xxx;dbname=xxx', 'xxx', 'xxx');
        }

        funtion FormatDate($input, $format="d-m-Y"){
            $input  = ($input)? $input : time();
            $format = ($format)? $format : "d-m-Y"; //als iemand toch het format leeg gooit...

                return date($format, $input);
        }

        funtion FormatTime($input, $format="H:i"){
            $input  = ($input)? $input : time();
            $format = ($format)? $format : "H:i"; //als iemand toch het format leeg gooit...

                return date($format, $input);
        }
    }

    class Engine extends Base {
        //Nog meer functies

        function Clear($data){
            unset($data);
        }
    }

    $Engine = new Engine();
    
        if(isset($_POST['submit'])){
            if(empty($_POST['naam'])){
                //error->naam is leeg
            } else {
                //PDO::Insert
                $Engine->Clear($_POST);
            }
        }
?>



Wat is PHP toch eigelijk een mooie taal om te zien :)

Veel mensen zeggen, gebruik unset dan dan direct. Nee, dat doe ik niet, nu bereid ik alles met een functie voor, maar wil ik later één ding veranderen hoef ik het maar 1 keer te doen IPV het hele script door te gaan met CTRL+F

:)

[Reactie gewijzigd op maandag 5 december 2011 12:25]


Door Tweakers user RobIII, maandag 5 december 2011 12:49

Waarom zou je überhaupt unsetten? En waarom is dat een task van je "engine"?
* Zo kan ik later alles aanpassen wat ik zou willen
* Zonder een heel script te verbouwen
Functies, encapsulaties en abstractielagen bestaan al langer dan vandaag hoor ;) En je was toch helemaal niet voor abstractielagen?

[Reactie gewijzigd op maandag 5 december 2011 13:10]


Door Tweakers user Blokker_1999, maandag 5 december 2011 13:16

Toppe schreef op maandag 05 december 2011 @ 11:04:
[...]


Ergens van een gare japanse thema website weg gehaald, was het enigste wat er een beetje uitzag... Ik zal de link wel ff opzoeken...

Maar goed, je zegt niet wat je er van vind 8)7
nope, is default van redmine.org . Gebruik hem zelf op een intraweb project met gemodificeerde kleurlayout :p .

Door Tweakers user ACM, maandag 5 december 2011 13:41

Toppe schreef op maandag 05 december 2011 @ 12:09:
Maar, stuur je hem dan terug als ingevuld formulier of als blanke data?

Ik heb bijvoorbeeld na ELKE execute van PDO de volgende functie:

[code ...]

Veel mensen zeggen, gebruik unset dan dan direct. Nee, dat doe ik niet, nu bereid ik alles met een functie voor, maar wil ik later één ding veranderen hoef ik het maar 1 keer te doen IPV het hele script door te gaan met CTRL+F
Imho hoor je niet aan de globals van PHP te komen, hooguit COOKIE en SESSION als je die gebruikt. Dingen er in veranderen, aan toe voegen of uit verwijderen zou imho uit den boze moeten zijn. De enige use case die ik kan voorstellen is als je e.o.a. wrapper eromheen hebt. Dan kan het nuttig zijn om elementen aan GET of POST toe te voegen of eruit te verwijderen om ze op de juiste wijze te populeren of om een alternatieve datacontainer ermee te vullen en gebruik daarvan af te dwingen.

Maar het leeg gooien van de requestdata is zeker geen taak van je databaselaag of iets dat standaard bij het opslaan van data hoort.

[Reactie gewijzigd op maandag 5 december 2011 13:42]


Door Tweakers user HammerT, maandag 5 december 2011 15:28

Prepared statements, en het scheelt ook nog eens in performance ;)

Door Tweakers user RobIII, maandag 5 december 2011 15:35

HammerT schreef op maandag 05 december 2011 @ 15:28:
en het scheelt ook nog eens in performance ;)
Dat is in de meeste gevallen verwaarloosbaar en in sommige gevallen zelfs helemaal niet waar. Zo zwart/wit als jij 't stelt is dus maar de halve waarheid; er zit een kern van waarheid in maar daar houdt 't op.

Neemt niet weg dat Prepared Statements 't any time winnen t.o.v. "SQL string concats"; performance of niet, dat laatste moet je gewoon zoveel mogelijk voorkomen.

[Reactie gewijzigd op maandag 5 december 2011 15:41]


Door Tweakers user riezebosch, maandag 5 december 2011 16:05

En wat als je met SQL injectie jezelf rechten kunt geven? Dan kan je alsnog de database droppen.

Door Tweakers user ACM, maandag 5 december 2011 16:24

riezebosch schreef op maandag 05 december 2011 @ 16:05:
En wat als je met SQL injectie jezelf rechten kunt geven?
Dan stonden je rechten in het begin al helemaal bijzonder ;)

Door Tweakers user Ventieldopje, maandag 5 december 2011 18:37

riezebosch schreef op maandag 05 december 2011 @ 16:05:
En wat als je met SQL injectie jezelf rechten kunt geven? Dan kan je alsnog de database droppen.
Met ACM ;) Bij een fatsoenlijke webhost heb je geen rechten om dat via SQL te doen, dit dien je te doen via je management paneel zoals cPanel / Plesk / DirectAdmin etc. ;)

Door Tweakers user Gomez12, maandag 5 december 2011 23:18

Simpele uitvoering die ik altijd gebruik is 1 admin-user die "alle" rechten op die dbase nodig heeft en die een backend en een frondend user aanmaakt (plugins kunnen bijv tabellen aanmaken etc). En daarnaast een FP-user die enkel select / update kan doe. Deletes zijn soft-deletes

Admin user staat enkel genoemd / gevraagd in install file

Door Tweakers user Gamebuster, dinsdag 6 december 2011 11:51

Ik heb liever dat al mijn data verwijderd wordt (en ik een backup heb) dan dat al mijn data op straat beland. Laat de scriptkiddies dan maar een DELETE * uitvoeren.

SQL injection ga ik tegen door geen SQL te gebruiken. Rails' ActiveRecord FTW.

zoals alle tools is niets 100% fool-proof, ook ActiveRecord not. Bij bijzonder gebruik kan SQL injection alsnog voorkomen bij gebruik van ActiveRecord, alleen voor "simplicity's sake" beschouw ik het als een wondermiddel tegen SQL injection in deze post om mensen te wijzen dat ActiveRecord gewoon awesome is.

[Reactie gewijzigd op dinsdag 6 december 2011 11:53]


Door Tweakers user Toppe, dinsdag 6 december 2011 12:11

Ik weet niet in hoeverre ActiveRecord is 'Ingeburgerd' maar als je natuurlijk iets ontwikkeld wil je wel dat het redelijk platform onafhankelijk is. Niet dat je eerst allerlei plugins hoeft te installeren...

Door Tweakers user Gamebuster, dinsdag 6 december 2011 14:49

Toppe schreef op dinsdag 06 december 2011 @ 12:11:
Ik weet niet in hoeverre ActiveRecord is 'Ingeburgerd' maar als je natuurlijk iets ontwikkeld wil je wel dat het redelijk platform onafhankelijk is. Niet dat je eerst allerlei plugins hoeft te installeren...
Ruby on Rails is standaard uitgerust met ActiveRecord. Ruby on Rails zelf is ook prima platform onafhankelijk (maar je moet wel Ruby + Ruby on Rails hebben en kennen)

Bovendien, een goede ActiveRecord implementatie kan je enorm veel tijd besparen, zoals vele andere goede plugins. Het is maar net waar je je tijd wilt insteken: Paar uurtjes kloten met een plugin die niet lekker te installeren valt (niet in RoR: daar voeg je 1 regel toe in je lijst met gewenste plugins en doe je "bundle install") en uitzoeken hoe-ie werkt, of een paar dagen/weken kloten om de functionaliteit zelf te schrijven.

[Reactie gewijzigd op dinsdag 6 december 2011 14:50]


Door Tweakers user Toppe, woensdag 7 december 2011 09:11

Gamebuster schreef op dinsdag 06 december 2011 @ 14:49:
[...]

Ruby on Rails is standaard uitgerust met ActiveRecord. Ruby on Rails zelf is ook prima platform onafhankelijk (maar je moet wel Ruby + Ruby on Rails hebben en kennen)

Bovendien, een goede ActiveRecord implementatie kan je enorm veel tijd besparen, zoals vele andere goede plugins. Het is maar net waar je je tijd wilt insteken: Paar uurtjes kloten met een plugin die niet lekker te installeren valt (niet in RoR: daar voeg je 1 regel toe in je lijst met gewenste plugins en doe je "bundle install") en uitzoeken hoe-ie werkt, of een paar dagen/weken kloten om de functionaliteit zelf te schrijven.
Dat noemen ze het wiel opnieuw uitvinden, sommige mensen zijn er gek op :)

Reageren is niet meer mogelijk