Kommentare zu: Security Patterns http://www.phphatesme.com/blog/sicherheit/security-patterns/ PhpHatesMe, but that's ok! Mon, 06 Feb 2012 20:59:49 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Von: Roland http://www.phphatesme.com/blog/sicherheit/security-patterns/comment-page-1/#comment-32490 Roland Sat, 13 Jun 2009 21:51:13 +0000 http://www.phphatesme.com/?p=2808#comment-32490 Hallo, zu diesem Thema gibt es ein gutes Buch, PHP Sicherheit von Christopher Kunz und Stefan Esser. (http://www.dpunkt.de/buch/2905.html) Darin werden die verschiedenen Angriffsszenarien beschrieben. Ich bin der Meinung, dass sich dieses Buch wirklich lohnt zu lesen bevor man mit PHP auf das Web losgeht ;) Hallo,
zu diesem Thema gibt es ein gutes Buch, PHP Sicherheit von Christopher Kunz und Stefan Esser. (http://www.dpunkt.de/buch/2905.html)
Darin werden die verschiedenen Angriffsszenarien beschrieben.
Ich bin der Meinung, dass sich dieses Buch wirklich lohnt zu lesen bevor man mit PHP auf das Web losgeht ;)

]]> Von: Daniel Liebmann http://www.phphatesme.com/blog/sicherheit/security-patterns/comment-page-1/#comment-32264 Daniel Liebmann Thu, 04 Jun 2009 10:27:25 +0000 http://www.phphatesme.com/?p=2808#comment-32264 Jein ;-) Es gibt zwar bereits ein oder zwei Repositories, aber mir ist keins bekannt das z.B. direkt auf eine Sprache wie PHP Bezug nimmt, sondern eher sehr allgemein gehalten sind, was wiederum bei der Umsetzung Fragen oder Probleme aufwirft. Ich bin der Meinung es sollte zu jeder Sprache ein Repository an Security Patterns geben, wobei die Betonung hier auf einem, das als Standard verstanden und auch so gepflegt und erweitert wird, geben. Aber das ist ,wenn auch ein erstrebenswertes Ziel, etwas das glaub ich in weiter Ferne liegt, da es einfach unglaublich viel Arbeit darstellet, zu dem sich erfahrene PHP Profis und Security Experten gleichermaßen aufraffen müssten. Jein ;-)

Es gibt zwar bereits ein oder zwei Repositories, aber mir ist keins bekannt das z.B. direkt auf eine Sprache wie PHP Bezug nimmt, sondern eher sehr allgemein gehalten sind, was wiederum bei der Umsetzung Fragen oder Probleme aufwirft.
Ich bin der Meinung es sollte zu jeder Sprache ein Repository an Security Patterns geben, wobei die Betonung hier auf einem, das als Standard verstanden und auch so gepflegt und erweitert wird, geben. Aber das ist ,wenn auch ein erstrebenswertes Ziel, etwas das glaub ich in weiter Ferne liegt, da es einfach unglaublich viel Arbeit darstellet, zu dem sich erfahrene PHP Profis und Security Experten gleichermaßen aufraffen müssten.

]]> Von: Michael http://www.phphatesme.com/blog/sicherheit/security-patterns/comment-page-1/#comment-32262 Michael Thu, 04 Jun 2009 08:29:35 +0000 http://www.phphatesme.com/?p=2808#comment-32262 Danke für den Artikel! Gibt es für Privatleute vielleicht eine Liste mit 100 Pattern, die man einfach mal abklappern kann und seine eigene Software drauf untersuchen kann? Ich könnte mir vorstellen, dass es schon fertige Repositories gibt. Danke für den Artikel!

Gibt es für Privatleute vielleicht eine Liste mit 100 Pattern, die man einfach mal abklappern kann und seine eigene Software drauf untersuchen kann? Ich könnte mir vorstellen, dass es schon fertige Repositories gibt.

]]> Von: Bonzei http://www.phphatesme.com/blog/sicherheit/security-patterns/comment-page-1/#comment-32032 Bonzei Fri, 29 May 2009 04:42:04 +0000 http://www.phphatesme.com/?p=2808#comment-32032 Arbeite gerade das Buch "Design Patterns" von Stefan Bergmann durch. Wenn man sich mal mit Patterns beschäftigt will man nicht mehr ohne Leben ;). Also bitte mehr davon, klingt sehr vielversprechend :) Arbeite gerade das Buch “Design Patterns” von Stefan Bergmann durch. Wenn man sich mal mit Patterns beschäftigt will man nicht mehr ohne Leben ;) .

Also bitte mehr davon, klingt sehr vielversprechend :)

]]> Von: PHPDave / David Olah http://www.phphatesme.com/blog/sicherheit/security-patterns/comment-page-1/#comment-32013 PHPDave / David Olah Thu, 28 May 2009 18:41:50 +0000 http://www.phphatesme.com/?p=2808#comment-32013 Ah gut, dann hab ich das bisher intuitiv gemacht, ohne dass Security Patterns mir ein Begriff waren :) Ah gut, dann hab ich das bisher intuitiv gemacht, ohne dass Security Patterns mir ein Begriff waren :)

]]> Von: Daniel Liebmann http://www.phphatesme.com/blog/sicherheit/security-patterns/comment-page-1/#comment-31981 Daniel Liebmann Wed, 27 May 2009 23:31:58 +0000 http://www.phphatesme.com/?p=2808#comment-31981 Danke, freut mich natürlich dass mein erster Beitrag scheinbar gut ankam :-) @Dave: Nein das ist nichts anderes, eher im Gegenteil, da hast du sogar ein sehr praktisches Beispiel gefunden, denn wie Security Patterns umgesetzt werden ist immer stark vom jeweiligen Umfeld abhängig. Die Idee hinter dem Entwurf ist hingegen immer derselbe: Sicherheitsfaktoren kontinuierlich so zusammen zu fassen, dass diese zukünftig leichter und früher erkannt und vermieden werden (im Idealfall schon vor dem eigentlichem Entwicklungsprozess). Danke, freut mich natürlich dass mein erster Beitrag scheinbar gut ankam :-)
@Dave: Nein das ist nichts anderes, eher im Gegenteil, da hast du sogar ein sehr praktisches Beispiel gefunden, denn wie Security Patterns umgesetzt werden ist immer stark vom jeweiligen Umfeld abhängig. Die Idee hinter dem Entwurf ist hingegen immer derselbe: Sicherheitsfaktoren kontinuierlich so zusammen zu fassen, dass diese zukünftig leichter und früher erkannt und vermieden werden (im Idealfall schon vor dem eigentlichem Entwicklungsprozess).

]]> Von: PHPDave / David Olah http://www.phphatesme.com/blog/sicherheit/security-patterns/comment-page-1/#comment-31973 PHPDave / David Olah Wed, 27 May 2009 16:59:03 +0000 http://www.phphatesme.com/?p=2808#comment-31973 Sehr schöner und hilfreicher Artikel, dennoch eine Frage zum Verständnis. Ist das etwas anderes, als dass man eben diverse Security-Thematiken zentralisiert? Als Beispiel kann ein Inputcleaner genannt werden, der bösen Code aus Request-Variablen filtert und diesen zugängig macht - sei es XSS oder anderes. So würden die "eigentlichen Devs" nur auf das $input-Objekt (Wenn der Inputcleaner eben im Objekt $input gespeichert ist) zugreifen und die Security-Profis würden nur die Input-Klasse ändern müssen, ohne dass die Devs etwas beachten müssen (es sei denn es wurden neue Funktionalitäten hinzugefügt natürlich). Sehr schöner und hilfreicher Artikel, dennoch eine Frage zum Verständnis.

Ist das etwas anderes, als dass man eben diverse Security-Thematiken zentralisiert?
Als Beispiel kann ein Inputcleaner genannt werden, der bösen Code aus Request-Variablen filtert und diesen zugängig macht – sei es XSS oder anderes.
So würden die “eigentlichen Devs” nur auf das $input-Objekt (Wenn der Inputcleaner eben im Objekt $input gespeichert ist) zugreifen und die Security-Profis würden nur die Input-Klasse ändern müssen, ohne dass die Devs etwas beachten müssen (es sei denn es wurden neue Funktionalitäten hinzugefügt natürlich).

]]>