Letzte Woche wurde Ruby on Rails in der Version 3.2.3 veröffentlicht. Neben einigen Bugfixes wurde auch einiges an der Sicherheit des Frameworks und dem Schutz vor unerlaubten Parametern bei mass assignment geändert.
Beim Erstellen einer neuen Rails 3.2.3 Applikation wird jetzt standardmäßig der Wert config.active_record.whitelist_attributes im applications controller auf true gesetzt. Durch diese Option wird eine Whitelist erstellt, die Attribute eines Models im Projekt enthält, welche durch mass assignment gesetzt werden können. Dadurch wird global im Projekt verhindert, dass ungewollt, mittels mass assignment, Attribute gesetzt werden.
Nun mal zu einem Beispiel. Nehmen wir an, wir haben ein User Model mit folgenden Attributen: name, password, is_admin. Das letzte Attribut gibt in unserem Beispiel an, ob der Benutzer ein Administrator unserer Seite ist. Bei unserem Registrierungsformular kann der Benutzer ein Usernamen und ein Passwort definieren. Die create action im User Controller würde folgendermaßen aussehen:
def create
User.create(params[:user])
endHier wird mittels mass assignment ein neuer User erstellt. Alles schön und gut. Nur was ist, wenn der User in den params noch das attribut :is_admin => true setzt? So könnte sich jeder als Admin registrieren.
Um dies zu vermeiden, gibt es die Option attr_protected, mit welche man gewisse Attribute vom Setzen durch mass assignment ausschliessen kann. Bei attr_protected :is_admin würde beim Setzen des is_admin Attributes dies nicht gespeichert werden. Alternativ können auch mit attr_accessible die Attribute angegeben werden, welche durch mass assignment gesetzt werden dürfen. Mit attr_accessible :username, :password können nur diese Werte mit User.create(params[:user]) gesetzt werden. Alle anderen Werte wären nil.
Aber zurück zu config.active_record.whitelist_attributes. Dieser Wert verlangt es in allen Models die Attribute für mass assignment zu bestimmen. Ist in einem Model keins der beiden Methoden (attr_protected / attr_accessible) gesetzt, können keine Attribute mittels mass assignment gestetzt werden. Ich persönlich finde die Option super. So ist der Entwickler vor bösen Überraschungen bewahrt. Aber um die Option zu nutzen müsst ihr jetzt nicht extra auf Rails 3.2.3 upgraden. Ich selbst habe das auch mit einer Rails 3.2. Applikation erfolgreich getestet.
Bei der Generierung und der Verwendung des authenticity_token in remote-forms hat sich ebenfalls etwas geändert. Remote-Forms sind HTML-Formulare, welche mittels XMLHttpRequest oder zu kurz mittels einem AJAX-Call abgesendet werden. Seit Rails 3.2.3 kann die Generierung des authenticity_token bei :remote => true mittels config.action_view.embed_authenticity_token_in_remote_forms = false abgestellt werden. Es wird für diese Art von Formularen kein hidden-field mit dem Authenticity Token generiert,
<input name="authenticity_token" type="hidden" value="" />
sondern das Token aus dem Meta-Tag genutzt. Aber wichtig hierbei: Das Formular kann bei deaktivierten JavaScript nicht mehr richtig versendet werden. Falls du die Generierung des Tokens standardmäßig deaktiviert hast, kannst du trotzdem mit der Option :authenticity_token => true ein Token in dem Formular generieren lassen.
Ich finde es sind schon einige interessante Änderungen in dem Update. Natürlich war das noch nicht alles. Was sich sonst noch geändert hat, könnt ihr hier nachlesen.
