eigenes cms

H

heinzelJacKy

0
hey leute!
hab mit nem freund zusammen ein eigenes content-management in php realisiert was zwar nicht riesenumfangreich ist aber doch ein paar funktionen enthält.
das ganze läuft momentan auf
http://jscms.js.funpic.de als eine art "public beta" oder so.
also wär meine 1. bitte dass sich vielleicht ein paar leute ein bisschen durchclicken und gerne ein paar seiten reinstellen, halt alle funktionen mal ausprobieren um eventuelle fehler zu finden. wenn sich wer mit xss etc auskennt, wär das auch hilfreich wenn jemand das testen wuerde.
2. hätte ich noch ne frage, da momentan dort bilder von joomla benutzt werden. joomla läuft ja unter der gpl, und ich bin mir nicht sicher ob ich, falls ich dieses content management verkaufen will, diese bilder mitliefern darf oder was es da fuer möglichkeiten gibt. selbst bilder erstellen wär natuerlich auch kein problem, aber bis jetzt habe ich nur auf die funktionalität geschaut und nicht primär auf design,ausserdem bin ich wohl net so begabt in sachen bildbearbeitung ;) genauso verhält es sich mit dem benutzten fck-editor und dem javascript-kalenderpicker.. kann mich da jemand aufklären wie das rechtlich aussieht? wär super :)

mfg jacky
 
jo also da gibts halt schon ein paar kleine bugs
Zum Vergrößern anklicken....

welche denn? wär net schlecht wenn du die aufzählen wuerdest :D
das pw "root" ist momentan hardgecodet und funktioniert fuer jeden existierenden benutzer, wird aber bei ner normalen version wohl net so sein ;)

tobt euch gerne aus ;-) solang sich net funpic beschwert weil ihr ihre server zerschossen habt is mir das grad recht..

achja, kennt sich jetzt jemand aus wie das mit den bildern etc ist?

mfg jacky
 
Original von heinzelJacKy
das pw "root" ist momentan hardgecodet und funktioniert fuer jeden existierenden benutzer, wird aber bei ner normalen version wohl net so sein ;)
Zum Vergrößern anklicken....

Es waere nicht schlecht, wenn du das rausmachst, damit es so ist wie in der spaeteren richtigen Version.

mfg
c1b
 
das xss sheet kenn ich schon und hab auch schon ein paar einfache methoden ausprobiert in richtung xss und sql-injection, aber da ich selber net viel erfahrung in der richtung hab sondern mich nur auf online-artikel verlassen kann, denke ich dass es wohl noch komplexere angriffsvektoren gibt an die ich net gedacht hab bei der programmierung..
mit dem hardgecodeten pw wollte ich verhindern, dass der erste spack ankommt und das admin-pw ändert und dann keiner mehr zugriff hat bis ich die db tilte ;-) man kann auch monentan noch das passwort fuer alle benutzer ändern und benutzen, aber das "root" ist so eine art master-pw das immer funktioniert. das ganze war einfacher, also in den scripts eine änderung des admin-pws zu unterbinden, deswegen wirds auch momentan noch so bleiben, am grundsätzlichen sicherheitsmodell ändert sich ja nix.

mfg jacky
 
Sieht aus als waere dein Login anfaellig fuer SQL-Injection.
Oeffne: http://jscms.js.funpic.de/index.php?act=1
Username: admin
Passwort:
Code: 
' OR 'X' = 'X
Dann bekomm ich oben die Leiste zu sehen, kann aber nicht darauf zugreifen (hab jetzt auch nicht die Zeit um weiter zu probieren).
Solltest auf jeden Fall mal danach schauen.

mfg
c1b
 
* Da sich der Schwerpunkt der Diskussion hier auf die Sicherheit konzentriert, in unser schönes neues Webmaster-Security Forum geschoben. :) *
 
Hey wenn du mir mal die Sources zukommen lassen würdest würd ich mal nach Lücken suchen das geht imo besser als auf ner Seite.
Ich würds aber auch verstehen wenn du sie nicht preisgeben willst ;)

Xalon
 
Um Wollen geht's aber nicht... Produkte, die andere Entwicklungen verwenden, die unter der GPL stehen, müssen ebenfalls unter die GPL oder eine gleichwertige Lizenz gestellt werden. Und die GPL besagt, dass die Sourcen offengelegt werden müssen ;)
 
Original von LX
Um Wollen geht's aber nicht... Produkte, die andere Entwicklungen verwenden, die unter der GPL stehen, müssen ebenfalls unter die GPL oder eine gleichwertige Lizenz gestellt werden. Und die GPL besagt, dass die Sourcen offengelegt werden müssen ;)
Zum Vergrößern anklicken....

Aber doch nur bei weitergabe, oder?
 
was mir noch eingefallen ist: durch das usermanagement eröffnet sich fuer einen benutzer, der zwar normal-user-rechte hat (termin-rechte bzw. rechte fuer bestimmte kategorien) eine neue angriffsmöglichkeit, da er ja html-code auf die seite stellen kann. heisst, wenn er eine seite erstellt, auf der er den cookie mit der session id der benutzer klaut (was er ja innerhalb seiner kategorie kann) kann er theoretisch die session-id des admins klauen, der angemeldet durch die seite surft.
muss ich von so einem fall ausgehen? und wenn ja, fällt irgendwem eine lösung dazu ein? den html-code zu escapen wäre ja wenig sinnvoll, und scripts rauszuschnippeln ist wohl auch eine zu große einschränkung fuer den endbenutzer.
Um Wollen geht's aber nicht... Produkte, die andere Entwicklungen verwenden, die unter der GPL stehen, müssen ebenfalls unter die GPL oder eine gleichwertige Lizenz gestellt werden. Und die GPL besagt, dass die Sourcen offengelegt werden müssen
Zum Vergrößern anklicken....
gehts hier nur um produkte oder um alle art software/webanwendung, die gpl-software verwendet? also muss ich momentan auch schon die sources veröffentlichen oder erst wenn ich das ding verkaufen wuerde?
und wie sieht das ganze aus, wenn ich nur meine eigenen sources verkaufen will und dann dem kunden als zusatzinformation empfehle, er soll sich die gpl-lizensierten pakete selbst installieren? wär das so eine beruehmte "grauzone" oder ist das auch schon böse?

mfg
 
Also wenn du gpl-"Produkte" nutzt musst du den Source freigeben (soweit ich weiß ;) )
Und ja du musst davon ausgehen das die User XSS Code auf ihre Seiten stellen...
Immer vom schlimmsten Fall ausgehen!

Xalon
 
ka ob des wichtig ist aber denke doch,
bei termin eintragen ist es möglich im text feld ein simples <script>alert(5);</script>
auszuführen.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben