Sony: Weitere Webseiten gehackt

[Pitlobster]

Jetzt ist Deine Meinung zu Sony: Weitere Webseiten gehackt gefragt.


Bitte beachtet: Der Kommentarbereich wird gemäߟ der Forenregeln moderiert.


Zum Artikel: Sony: Weitere Webseiten gehackt

 

[doctorodoom]

tja, das hat man halt davon wenn man sich mit geohot anlegt. dumm gelaufen sony ^^ das sollte denen eine lehre sein für die zukunft.

 

[smash brother]

genau. was fällt denen bei sony überhaupt ein geld einnehmen zu wollen, wir arbeiten ja auch alle nur weil uns sonst langweilig wäre.

 

[ShiYanLu]

Und wem schafet man noch damit ?
Genau, all den Kunden und Leuten.
Super Sache, ich finde solche Verbrecher und was anderes sind es nicht, gehoeren hinter Schloss und Riegel.
Hauptsache ein paar Leute fuehlen sich toll dabei, was kuemmert einem das Leid anderer nciht wahr ? ^^

 

[nezu]

@doctordoom wer sagt denn, dass es der ach so tolle geohot es war?

Wem bringt das ganze eigentlich was? Dem Kunden sicherlich nicht..den Gamern erst recht nicht. Also im Grund eigentlich nur den paar Pseudo-Robin-Hoods, die sich wohl jetzt unglaublich toll finden.

 

[fxnox]

diese geschichte wird sony langsam zu gross..und kaum mehr aufzufangen..ich kenn jetzt schon drei leute aus meinem näheren umfeld, die mittlerweile von der ps3 abgelassen haben, sie verkauft haben und eine 360er gekauft haben...nicht, weil ihnen das online spielen gefehlt hat, sondern: weil sie es satt haben, dass sony daten auf die reise schickt, indem sie sie den hackern scheinbar ungeschützt zum fraß vorwerfen...

 

[schwarzer]

Der neue Slogan - Playstation, des Hackers Freuden .

 

[Socke]

"Und wem schafet man noch damit ?
Genau, all den Kunden und Leuten."

Am meisten schadet man damit noch immer Sony. Oder glaubst Du, dass 2-3 Wochen nicht spielen können ein größerer Schaden ist als der Gesichtsverlust + der finanzielle Aufwand von Sony?
So gesehen gehen die Aktionen an genau die beabsichtigte Adresse.

Für Leute die das Wort Datenschutz kennen und es Leid sind überall ihre Daten angeben zu müssen kann das am Ende sogar nützlich sein.
Eventuell geht mehreren Leuten mal ein Licht auf und sie verzichten lieber auf die Onlinedienste, wenn sie sich vorher datentechnisch zwingend nakig machen müssen.
Was zur Folge haben könnte, dass Unternehmen auf diese Datensammelei verzichten müssen, wenn sie weiterhin Kunden haben wollen.

Allerdings müssten diese Angriffe dann noch stark (nicht nur auf Sony) ausgeweitet werden. Am Ende könnte das wirklich für die Kunden etwas bringen. Ich habe allerdings so meine Zweifel, dass das auch so zu ende gebracht wird.

 

[HadoVebeap]

Lächerlich, einfach nurnoch lächerlich.
Ich werde mich hüten mich jemals wieder bei irgend einem Dienst von Sony anzumelden.

 

[mogry]

Sony ist echt am arsch.
Sony hat jetzt noch ein viel schlechteren ruf als vorher.
Ich hoffe die scheiss hacker lassen das mal wieder.

 

[Carbal]

[No message]

 

[TAPETRVE]

Wie gesagt, sieh's von der positiven Seite. Je mehr Vollspaten sich von ihrem Krempel trennen, desto friedlicher wird es später im SONY-Netzwerk. Ein Sturm der Säuberung, quasi .

 

[Carbal]

@TAPETRVE

Habe meinen Kommentar zwar wieder gelöscht, da ich doch keine Lust auf die Diskussion habe und diese ohnehin unnötig ist, aber Dir muss ich jetzt noch zustimmen! =)

Das ist wirklich das Gute daran, dass Leute, die nicht von der Wand bis zur Tapete denken können, abspringen und die PS3-Community ein paar Nassbirnen weniger hat. Tolle Sache an und für sich!

 

[Kuru]

Also langsam tut mir Sony beinahe schon leid. Beinahe.

 

[Abnaxos]

SQL-Injection! Unglaublich! Die einfachste Sicherheitslücke, die es gibt. So offensichtlich, dass es gar nicht als «Sicherheitslücke» zu bezeichnen ist, sondern als Einladung. Die schicken ihre Entwickler wohl schnell eine Woche in einen Grundkurs bevor sie sie auf ihre sicherheitskritischen Systeme loslassen. Wobei, nein, das kann nicht sein, denn nach einem 1-wöchigen Grundkurs sollte man bereits gelernt haben, was SQL-Injection ist …

 

[Kuru]

Was genau IST denn SQL-Injection? Mal so für den Laien...

 

[Dudo]

@Kuru
http://de.wikipedia.org/wiki/SQL-Injection

 

[Abnaxos]

Ein stark vereinfachtes Beispiel: Nehmen wir ein Suchfeld an. Nun wird folgende Abfrage an die DB geschickt:

SELECT * FROM tabelle WHERE name LIKE ´%Inhalt-des-Suchfelds%´

Also alle Zeilen aus der Tabelle, deren Feld "name" den eingegebenen Suchbegriff enthält. Nun mache ich folgende Suchabfrage:

´; DROP DATABASE beliebige_datenbank; SELECT * from tabelle where name =´

Mit meiner Eingabe ins Suchfeld schliesse ich also die Suchabfrage ab, füge eigene Befehle oder Abfragen ein, und sorge am Ende noch dafür, dass es keinen Syntax-Fehler gibt. Im obigen Beispiel hätte ich jetzt einfach eine Datenbank gelöscht.

Wenn also der Inhalt von Formularfeldern 1:1 in die ursprüngliche Abfrage übernommen wird, kann man böse Befehle an die Datenbank schicken und damit Blödsinn anstellen – oder eben auch mehr als nur Blödsinn, z.B. Daten heraus holen, die einen nichts angehen.

Das ist ein absoluter Anfängerfehler …

 

[Wingy]

Um die Datenbank abzufragen musst du schon den Usernamen zumindest kennen, den originalen (nicht ghost)port, Passwort des Webservers und des SQL-Servers... ausser es wurden die Standards übernommen. Davon gehe ich mal nicht aus, denn sonst wäre es Sicherheit=0 und der "Admin" der Tabelle wäre sinnlos ...

 

[Abnaxos]

Login und Verbindung zur Datenbank werden ja von der Web-Applikation erledigt, um die Suchabfrage überhaupt ausführen zu können. Es werden einfach weitere Befehle eingefügt.

Richtig ist, dass das, wie ich geschrieben habe, ein stark vereinfachtes Beispiel ist: Jedenfalls muss man die Namen der Tabellen etc. kennen. Sowas kann man allerdings auch abfragen. Weiterhin läuft das so eingeschmuggelte SQL mit den Rechten des Logins der Web-Applikation, man kann also über die Rechte verhindern, dass man so einfach Dinge anstellen kann, die man nicht anstellen soll. Tatsächlich ist es aber häufig so, dass die Web-Applikation auf ihrer DB alles darf – weil sie es dürfen muss, um funktionieren zu können.

Einfacher und effizienter ist es auf jeden Fall, zu verhindern, dass SQL-Injection überhaupt möglich ist, dort sollte man beginnen. Zusätzliche Massnahmen schaden natürlich auch nicht.