Antworten: 22
|
|||||||
 duRiel  Weltmeister  Herkunft: Cambridge Beiträge: 7300 |
# Thema - 18.11.2008 um 17:31 Uhr
Hey Community, speziell Addon Entwickler! Ich habe eine Funktion erstellt, die die Sicherheit von Clansphere erhöhen soll. Ab dem nächsten Clansphere Release werden die Variablen $_POST, $_GET sowie $_REQUEST nicht mehr zur Verfügung stehen. $_REQUEST wird komplett gesperrt. An die Variablen von $_GET und $_POST kann dann nurnoch über die neu eingebaute Funktion herangekommen werden. Um die Variablen von $_GET zu bekommen, benötigt man folgende Zeile:
Damit werden alle Variablen von $_GET mit cs_sql_escape gesichert und dann in $cs_get gespeichert. Zusätzlich sollte man sich überlegen, welche Variablen integers, also ganze Zahlen sind. Diese werden als Parameter an die Funktion übergeben:
Dadurch werden alle $_GET Variablen escaped in $cs_get gespeichert und $_GET['id'], $_GET['where'] und $_GET['sort'] explizit als ganze Zahlen gespeichert. Das gleiche gilt für
Bitte sorgt dafür, dass eure alten Addons auch bei der neuen Version funktionieren, indem ihr die auf die Verwendung von $_GET, $_POST und $_REQUEST verzichtet und statt dessen cs_get() und cs_post() verwenden. Neue addons sollten bitte auch mit diesen Funktionen entwickelt werden. DasGanze wird die Sicherheit von Clansphere nachhaltig verbessern. Bitte helft uns dabei, indem ihr eure Addons aktualisiert und somit auf die Zukunft vorbereitet und auch sicher macht. Danke, duRiel Zuletzt editiert von duRiel
am 18.11.2008 um 17:36 Uhr (1x Editiert) |
||||||
Inaktiv |
  |
||||||
 MindcrimeGeekboy  Beiträge: 1155 |
# Antwort: 1 - 18.11.2008 um 22:10 Uhr
Ah, gluecklicherweise seh ich schon das du auch die moeglichkeit bietest um die variablen in original form zu behalten... Was aber fehlt is das ich diese funktion nicht mehrmals befragen kann... Beim 2. anruf der selbe function ist der spass vorbei und bekommt ich nichts mehr zurueck... Er loesscht $_POST und $_GET ohne das resultat von den function irgendwo static zu speichern... Diesen ersatz funktion sollte diesselbe funktionalitaet haben wie das "original"... Und ich wurde das eh diese funktionalitaet eh als OPTIONAL machen innerhalb ClanSphere. Standard vielleicht an in die neue versionen, aber so lange es noch viele alte nicht geaenderte module gibt muss es die moeglichkeit geben aus zu schalten das es $_POST und $_GET nicht mehr gibt... Und sowas bringt eigentlich auch nur fake sicherheit... Database value escaping sollte eigentlich durch einen datenbank layer gemacht werden am letzten moment und nicht irgendwo gleich am anfang von request... Genause wie XML/HTML escaping so spaet wie moeglich beim response gemacht werden soll... Zuletzt editiert von Mindcrime am 18.11.2008 um 22:22 Uhr (4x Editiert) |
||||||
Inaktiv |
|  |
||||||
 Fr33z3m4n Medal of Honor  Herkunft: Hamm Beiträge: 11094 |
# Antwort: 2 - 18.11.2008 um 22:18 Uhr
Erstmal wurden die funktionen nur erstellt. $_GET, $_POST usw. bleiben so lange erhalten, bis ALLE module darauf umgestellt sind. Soltle ja nicht von heute auf morgen passieren, von daher geben wir jedem Entwickler der Module genügend Zeit dieses darauf umzustellen. Wieso willst du die $cs_get doppelt abfragen ? Speicher diese doch in einer seperaten var, oder seh ich das falsch ?! ------------------ mfg Patrick "Fr33z3m4n" Jaskulski  Antoine de Saint-Exupéry: Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu verteilen, sondern lehre die Männer die Sehnsucht nach dem endlosen weiten Meer. |
||||||
Inaktiv |
 | |
||||||
| Mindcrime Geekboy Beiträge: 1155 |
# Antwort: 3 - 18.11.2008 um 22:28 Uhr
18.11.2008 um 22:18 Uhr - Fr33z3m4n: Wieso willst du die $cs_get doppelt abfragen ? Speicher diese doch in einer seperaten var, oder seh ich das falsch ?! Du meinst also: $get = cs_get(array(),array_keys($_GET)); global $_GET; $_GET = $get; Dan sind wir genau wieder zurueck wo wir vorher waren... Wenn ich functions in mein modul hab, dan haette ich kein bock entweder jedes mal diesen var als parameter weiter zu geben, oder am start den jedes mal als global zu stellen: $get = cs_get(array(),array_keys($_GET)); function meine_function($get, $var1, $var2) { // mach mein ding } meine_function($get, $var1, $var2) oder: global $get; $get = cs_get(array(),array_keys($_GET)); function meine_function($var1, $var2) { global $get; // mach mein ding } meine_function($var1, $var2) Deswegen ist ja $_GET und $_POST ein SUPERGLOBAL... Zuletzt editiert von Mindcrime am 18.11.2008 um 22:30 Uhr (1x Editiert) |
||||||
Inaktiv |
| |
||||||
| Fr33z3m4n Medal of Honor Herkunft: Hamm Beiträge: 11094 |
# Antwort: 4 - 18.11.2008 um 22:32 Uhr
richtig, aber anders hast du dann nicht die absicherung in den functionen enthalten. Entweder sicherst du dann in der function nochmals ab, oder nimmst die abgesicherten vars aus cs_get ------------------ mfg Patrick "Fr33z3m4n" Jaskulski Antoine de Saint-Exupéry: Wenn Du ein Schiff bauen willst, so trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu verteilen, sondern lehre die Männer die Sehnsucht nach dem endlosen weiten Meer. |
||||||
Inaktiv |
| |
||||||
| duRiel Thread-Ersteller Weltmeister Herkunft: Cambridge Beiträge: 7300 |
# Antwort: 5 - 18.11.2008 um 22:48 Uhr
optional will ich es gerade nicht machen, damit man sich darüber bewusst wird, was man da mit den benutzereingaben anstellt. in den meisten fällen ist das auch einfach nur $cs_get = cs_get() mit höchstens ein paar integern. warum willst du alle werte unbelastet haben? doppelt wird man die funktion aufrufen können. das ist zur zeit nur so weil ich $_POST und $_GET noch nicht löschen kann und die funktion deshalb noch ein bisschen anders funktioniert als ich es vorhabe. warum soll das fake sicherheit sein? sicher ist es. datenbank layer sind uns zur zeit zu aufwendig. |
||||||
Inaktiv |
| |
||||||
| Mindcrime Geekboy Beiträge: 1155 |
# Antwort: 6 - 18.11.2008 um 23:02 Uhr
Meine meinung nach sollte cs_sql_escape() am letzten moment erst benutzt werden. Also beim eintrag in die datenbank und nicht vorher... Oder man benutzt ein ORM der das automatisch fuer dich macht, wie z.b. Propel (propel.phpdb.org). Das will aber auch nicht heissen das man automatisch sicher ist vor SQL injection. Selbst bei sowas muss man bestimmte dinge beachten als programmierer... Was ihr jetzt baut ist dasselbe als wenn ihr gleich alle daten die aus den SQL datenbank mit ein query kommen ein cs_secure() gibt oder htmlentities()... Escaping von HTML/XML sollte in die praesentations/view (end) phase gemacht werden und nicht gleich am anfang... Was ihr mit diese funktionalitaet hier versucht, ist es schlechte programmierer, bzw leute die keine ahnung haben von die security probleme beim schreiben von webscripte, das leben leichter zu machen so das sie noch weniger darueber nachdenken was fuer ein scheisse sie bauen... Und leute die wenigstens ein bissel davon ahnung haben es schwieriger zu machen ihren code zu bauen... Zuletzt editiert von Mindcrime am 18.11.2008 um 23:14 Uhr (4x Editiert) |
||||||
Inaktiv |
| |
||||||
| duRiel Thread-Ersteller Weltmeister Herkunft: Cambridge Beiträge: 7300 |
# Antwort: 7 - 18.11.2008 um 23:12 Uhr
Meine meinung nach sollte cs_sql_escape() am letzten moment erst benutzt werden stimmt theoretisch, begründung kommt später Also beim eintrag in die datenbank und nicht vorher... beim eintrag in die datenbank kann es schon zu spät sein, man kann ja vorher auch einiges damit anstellen. Oder man benutzt ein ORM der das automatisch fuer dich macht, wie z.b. Propel (propel.phpdb.org). Das will aber auch nicht heissen das man automatisch sicher ist vor SQL injection. Selbst bei sowas muss man bestimmte dinge beachten als programmierer... Was ihr jetzt baut ist dasselbe als wenn ihr gleich alle daten die aus den SQL datenbank mit ein query kommen ein cs_secure() gibt oder htmlentities() Was ihr mit diese funktionalitaet hier versucht, ist es schlechte programmierer, bzw leute die keine ahnung haben von die security probleme beim schreiben von webscripte, das leben leichter zu machen so das sie noch weniger darueber nachdenken was fuer ein scheisse sie bauen... eigentlich hast du damit recht. aber bei allem anderen bin ich mir zu 100% sicher, dass dadurch sicherheitslöcher entstehen. es denken nunmal die wenigsten während sie "entwickeln" an die sicherheit. du hast recht damit, dass es besser wäre, das nicht so automatisch im vorfeld zu machen sondern das dem entwickler selbst zu überlassen. aber genau das kann ich nicht machen. den leuten passieren einfach zu viele fehler. noch weniger über security nachdenken tun sie dabei auf keinen fall. die meisten denken normalerweise überhaupt nicht daran, und durch die funktion werden sie zumindest dazu angeregt zu überlegen welche variablen integers sind. machen wir es fortgeschrittenen entwicklern tatsächlich so viel schwerer? |
||||||
Inaktiv |
| |
||||||
| Mindcrime Geekboy Beiträge: 1155 |
# Antwort: 8 - 18.11.2008 um 23:14 Uhr
Btw, was wird den aus cs_sql_insert() / cs_sql_update() ?? Da wird schon ein mysql_real_escape_string() gemacht... Das heisst wenn man einfach nur cs_get() benutzt wird ein doppelter escape in den datenbank gemacht und aus " wird dan ein \\\" werden... Die machen (obwohl auch nicht so wie es richtig soll) es auf den richtigen platz... Und das wird dan also kaput gemacht... beim eintrag in die datenbank kann es schon zu spät sein, man kann ja vorher auch einiges damit anstellen. Und was? Wenn es output auf der page ist soll kein SQL escape kommen, sondern ein cs_secure() oder htmlentities? Wenn als XML soll ein xmlentities() her. Laden von eine dateipfad, vielleicht realpath() und noch andere abfragen... Was man dan machen muss haengt von functionaliteit ab die man erreichen will, und cs_sql_escape() ist NUR spezifisch fuer datenbank... machen wir es fortgeschrittenen entwicklern tatsächlich so viel schwerer? Ja, weil ich dan jedes mal darueber nachdenken muss ob es die "raw data" war, oder ob die schon "escaped" war, was ich vielleicht wieder "unescaped" haben moechtte... Jetzt weiss ich sicher das es "raw data" ist... Zuletzt editiert von Mindcrime am 18.11.2008 um 23:53 Uhr (4x Editiert) |
||||||
Inaktiv |
| |
||||||
| duRiel Thread-Ersteller Weltmeister Herkunft: Cambridge Beiträge: 7300 |
# Antwort: 9 - 18.11.2008 um 23:27 Uhr
das mit cs_sql_insert muss ich mir ansehen, ist aber nicht das problem. was wird kaputt gemacht? damit dass es speziell für dbs ist hast du recht. sql ist zwar das hauptproblem, aber mit xss ist auch nicht zu spaßen. wird dann eben wieder komplizierter. wir müssen da einen mittelweg gehen zwischen simplizität und sicherheit. vielleicht hast du recht damit, dass ich zu sehr auf simplizität geachtet habe. was schlägst denn du umsetzbares vor? |
||||||
Inaktiv |
| |
||||||
| josch Try to beat me Beiträge: 188 |
# Antwort: 10 - 18.11.2008 um 23:39 Uhr
Ich würd mich im großen und ganzen Mindcrime anschließen... Es mag sein, das aus eurer Sicht die Sicherheit erhöht wird, allerdings behaupte ich mal, das es auch Leute abschreckt... es gibt jetzt schon relative wenige die Addons schreiben... einige sind aufgrund der "einfachheit" von CSP zu diesem CMS gestoßen, durch die wegnahme von $_GET, $_POST und der Einführung neuer Funktionen denke ich das dies ein Grund ist nicht CSP zu nehmen (Einarbeitungszeit)... Als ich das gelesen habe, dachte ich sofort an meine Page und daran welches CMS ich nehmen sollte... ob ich wechseln sollte oder einfach "niemals" updaten... Dies optional einzubauen würde jedenfalls eine gute Lösung schaffen... Gruß ------------------ Der Vorteil der Klugheit besteht darin, daß man sich dumm stellen kann. Das Gegenteil ist schon schwieriger. |
||||||
Inaktiv |
| |
||||||
| duRiel Thread-Ersteller Weltmeister Herkunft: Cambridge Beiträge: 7300 |
# Antwort: 11 - 18.11.2008 um 23:45 Uhr
mindcrime hat einen ganz anderen standpunkt als du. gerade das abschrecken soll diese funktion nicht machen. du musst doch einfach nur $cs_get = cs_get() schreiben und dann überall $cs_get statt $_GET verwenden! |
||||||
Inaktiv |
| |
||||||
| Mindcrime Geekboy Beiträge: 1155 |
# Antwort: 12 - 19.11.2008 um 00:19 Uhr
Oh ja, ganz vergessen... Was du machst ist eigentlich genau dasselbe wie magic quotes benutzen: http://nl.php.net/manual/en/security.magicquotes.php Das wird nicht ohne grund schon nicht mehr benutzt und aus php6 entfernt... Nichts persoehnlichs gegen dir, duRiel, finde es schoen das du dich fuer dieses projekt einsetzt, nur diese idee finde ich halt nicht so gut... |
||||||
Inaktiv |
| |
||||||
| duRiel Thread-Ersteller Weltmeister Herkunft: Cambridge Beiträge: 7300 |
# Antwort: 13 - 19.11.2008 um 15:42 Uhr
habe ich auch schon dran gedacht. hast schon recht, aber so wie du dir das vorstellst kann ich das einfach nicht einbauen. du siehst ja selbst dass nur mit dieser funktion, bei der die leute nur eine zeile über ihre variablen nachdenken müssen, josch schon abgeschreckt wird. ich kann da keine allzu komplexen systeme verwenden. wie gesagt, man muss da einen mittelweg gehen. was schlägst du denn umsetzbares vor? so, dass es immernoch viele addons aus der community gibt? |
||||||
Inaktiv |
| |
||||||
| Mindcrime Geekboy Beiträge: 1155 |
# Antwort: 14 - 19.11.2008 um 17:25 Uhr
Wenn du ueberhaupt sowas machen willst: Mach eine main config / install eine globale variable $cs_main['secure_get_post'] (oder $secure_get_post, oder das was am besten die funktionalitaet deckt) in setup.php. Entweder beim install von neue version von ClanSphere oder default einstellen auf true. Wenn true unset() $_POST und $_GET und verpflichtet den benuetzung von cs_get() function. Wenn false kannst cs_get() noch immer benutzen aber $_POST und $_GET werden nicht unset() und NICHT geaendert (benutz also ein static $_CS_GET / $_CS_POST variable um die geaenderte daten zu speichern fuer mehrere cs_get() anrufen). Du hast dan: - Beim neuen install von ClanSphere das default dein "secure" modus eingeschaltet steht - Das wenn benutzer nur die neue version oder nur addons compatibel mit diese neue version benutzen, das sie diesen "secure" modus eingeschaltet bleibt. - Wenn benutzer probleme haben mit bestimmte module, das sie dan selber das ausschalten koennen, und also selber die entscheidung treffen ein moeglich groesseres risiko zu nehmen (im setup.php solltet deutlich ein tekst stehen das dies auch andeutet: PAS AUF, WENN AUF FALSCH...). Aber module die compatibel sind arbeiten noch immer, weil cs_get noch immer funkzt und die bleiben auch "secure"... So bleibt man auch backwards compatibel fuer alte module wenn die benutzer es wuenschen... Am schoensten waehre noch pro modul/addon das einstellen zu koennen, aber das ist ein bissel viel gefragt... Das default auf true einbauen hat aber grosse folgen fuer den cs_sql_insert() und cs_sql_update()... Zuletzt editiert von Mindcrime am 19.11.2008 um 17:26 Uhr (1x Editiert) |
||||||
Inaktiv |
| |
||||||
| duRiel Thread-Ersteller Weltmeister Herkunft: Cambridge Beiträge: 7300 |
# Antwort: 15 - 19.11.2008 um 17:34 Uhr
huh, ich hab ja was anderes erwartet, hätte nicht gedacht dass du dich mit nem an/aus schalter zufrieden gibst  so ne variable kann ich machen, vielleicht einfach ne zeile in der index.php. das mit cs_sql_insert und update bekomme ich bestimmt in den griff. gruß duRiel |
||||||
Inaktiv |
| |
||||||
 fay-painSpecialist Beiträge: 2006 |
# Antwort: 16 - 19.11.2008 um 17:53 Uhr
Mhh.. hätt ich jetzt auch nicht gedacht... also geht ja es ja im Endeffekt nur um die Kompatiblität der alten Module... Wenn dann sollte sowas aber nicht dem Ottonormaluser schon in der Installation bedrücken. Würde viele Nutzer abschrecken bei der Installation eine Entscheidung zu treffen, von der sie keinen Schimmer haben. Ähnlich wie Sha1 oder MD5 
------------------ Manchmal hast du fay und machmal pain. - hajo |
||||||
Inaktiv |
| |
||||||
| SCHIRI Weltmeister Herkunft: Hamburg Beiträge: 5299 |
# Antwort: 17 - 19.11.2008 um 18:00 Uhr
aggree @fay, wenn man jetzt nen schalter für die funktion baut, gibt es 2 möglichkeiten: standard AN: viele module werden nicht umgestellt werden und es wird 10000 threads geben "warum geht das modul nicht" standard AUS: niemand wird es einschalten und die funktion ist relativ sinnlos mindcrimes agrumentation leuchtet aber ein. wie wärs damit, dass post/get[id, where, start, sort] automatisch in integers verwandelt werden? andere paramer werden ja sowieso nirgens benutzt und auch die meisten custom-module übernemen ja diese parameter. und bei formularen wird die ausgabe ja meist (immer?) per cs_sql_update- oder insert verarbeitet, wo ja sowieso schon escaped wird. ------------------ www.laszlokorte.de |
||||||
Inaktiv |
| |
||||||
| Mindcrime Geekboy Beiträge: 1155 |
# Antwort: 18 - 19.11.2008 um 18:05 Uhr
Config settings 4tw halt... Mir ist es wayne, so lange ich es einfach ausschalten kann wenn es mir im wege steht... Aber IMHO es ist noch immer eine schlechte idee das zu tun... In prinzip willst du nicht das schlechte programmierer module machen, letztendlich bricht dir sowas auf. Klar, man hat dan viel mehr leute die module entwickeln, aber ob das die projekt besser machen oder den ruf von die kwalitaet des software projekts... standard AN: viele module werden nicht umgestellt werden und es wird 10000 threads geben "warum geht das modul nicht" standard AUS: niemand wird es einschalten und die funktion ist relativ sinnlos Ja, aber auf diese "warum geht das modul nicht" fragen, gibts dan eine einfache antwort im FAQ: "Geh zum setup.php und stelle variable auf false... aber pas auf, blablabla..." Zuletzt editiert von Mindcrime am 19.11.2008 um 18:07 Uhr (1x Editiert) |
||||||
Inaktiv |
| |
||||||
| SCHIRI Weltmeister Herkunft: Hamburg Beiträge: 5299 |
# Antwort: 19 - 19.11.2008 um 18:10 Uhr
Ja, aber auf diese "warum geht das modul nicht" fragen, gibts dan eine einfache antwort im FAQ: ja das wird dann natürlich so gemacht, nur dann wiederum werden alle das ausschalten, weil jeder irgendein modul benutzen will, was nicht dafür gemacht ist.
"Geh zum setup.php und stelle variable auf false... aber pas auf, blablabla..." ------------------ www.laszlokorte.de |
||||||
Inaktiv |
| |
||||||
| fay-pain Specialist Beiträge: 2006 |
# Antwort: 20 - 19.11.2008 um 18:19 Uhr
19.11.2008 um 18:10 Uhr - SCHIRI: Ja, aber auf diese "warum geht das modul nicht" fragen, gibts dan eine einfache antwort im FAQ: ja das wird dann natürlich so gemacht, nur dann wiederum werden alle das ausschalten, weil jeder irgendein modul benutzen will, was nicht dafür gemacht ist. "Geh zum setup.php und stelle variable auf false... aber pas auf, blablabla..." Genau! Aber ich seh da auch nicht das Problem in den "alten" Modulen die neuen Funktionen einzubauen. So viele sind es nicht und die Leute die hier aus der Community Module entwickeln, werden mit dieser Kleinigkeit schon fertig, da gibt es weit aus schwierigere Funktionen zu verstehen 
------------------ Manchmal hast du fay und machmal pain. - hajo Zuletzt editiert von fAY-pA!N am 19.11.2008 um 18:20 Uhr (1x Editiert) |
||||||
Inaktiv |
| |
||||||
 Dieses Thema wurde von ichraffsnicht  geschlossen. |
|||||||
Antworten: 22
|
|||||||
News - Features - Downloads - Forum - Team - Support - Switch View: Screen
Login - Registrierung - Passwort vergessen
ClanSphere Project - Mailus - Imprint - Disclaimer - Scriptinfo