Niet-onderbouwde weblinks php. Hacks en add-ons

De YRC Weblink-browser is gemaakt en gedistribueerd door het Indiase softwarebedrijf YRC Group Inc. En daarom is de standaardstartpagina de Indiase Google :))

Indiase programmeurs worden beschouwd als een van de coolste ter wereld (na Russisch en Chinees :), maar er is iets niet gelukt met deze browser, omdat het gewoon een soort vakantie is, geen browser. De ideeën die ze in deze browser probeerden te implementeren zijn geweldig, maar de implementatie zelf is erg slecht. De browser werkt "door de kieren", dat wil zeggen vreemd en slecht. Ik heb het op twee verschillende computers geprobeerd - Windows 7 en Windows 8 - en er waren op beide computers problemen en vastlopen.

Laten we echter in volgorde gaan.

Na de installatie vraagt ​​de browser u enkele instellingen te selecteren (zoals bijvoorbeeld te zien in de bovenstaande schermafbeelding) en daarnaast een account aan te maken voor cloudsynchronisatie en opslag van instellingen, bladwijzers, notities en bestanden.

Goed idee! Ik klik op de link Aanmelden, wat 'Registreren' betekent, er wordt een site geopend met grappige afbeeldingen, maar om de een of andere reden wordt deze niet geopend in YRC Weblink, maar in de browser die standaard op de computer is geïnstalleerd, en dit is de eerste vreemde ding. Een ander vreemd ding is dat je behoorlijk veel gegevens moet invoeren - waarom? Om u in de Maxthon-browser bijvoorbeeld te registreren in de cloud hoeft u alleen uw e-mailadres en wachtwoord in te voeren, wat veel eenvoudiger en prettiger is en geen onnodige vragen oproept.

Oké, ik zal al deze gegevens invoeren. Ik ontvang een brief om mijn account te bevestigen, ik klik op de link, maar de site zegt: "Oeps - ik kan uw gegevens niet vinden in de database." Maar dan komt er weer een brief met een nieuwe link, ik klik op de link erin en nogmaals - Oeps! Tijdens deze oeps komt er echter een derde brief binnen waarin staat: gefeliciteerd, uw account is bevestigd! Dit is een soort Indiase accountverificatie.

Ik open de browser, de instellingen en probeer bladwijzers te importeren. De browser ziet het bladwijzerbestand niet in het .html-formaat, wat alle browsers die ik ken zonder problemen kunnen zien, begrijpen en accepteren. Ik voer de bestandsnaam handmatig in, klik op Importeren en ontvang een rapport - de bladwijzers zijn succesvol geïmporteerd!

Maar waar werden ze met succes geïmporteerd??? Ze bevinden zich noch in de browser, noch in de cloud. Ik herhaal de handeling opnieuw en hetzelfde resultaat. Laat maar zitten. Laten we verder gaan.

In de cloud en instellingen is er een Notes-item. Terwijl ik de notities in de Maxthon-browser onthoud, die kunnen worden gemaakt met het ingebouwde notitieblok en die automatisch in de cloud worden opgeslagen, probeer ik iets soortgelijks te vinden in YRC Weblink, helaas zonder succes. Er is een weergave voor notities, maar er is geen tool om deze te maken. Vreemd? En hoe!

Nou oke. Laten we eens kijken wat we nog meer hebben. Tijdens de installatie installeerde de browser zelf (zonder te vragen) twee snelkoppelingen op het bureaublad: een browsersnelkoppeling (dit is normaal) en een Twitter-snelkoppeling.

Als u op deze snelkoppeling klikt, wordt een apart browservenster met Twitter geopend. Waarom zou je dit in godsnaam doen, en zelfs standaard? Misschien gebruik ik Twitter helemaal niet? Oké, ik heb de Twitter-snelkoppeling van mijn bureaublad verwijderd, maar dat is niet gelukt! Wanneer u nu op de browsersnelkoppeling klikt (niet op Twitter), wordt de browser gemarkeerd met Twitter in de taakbalk! Ik heb nog nooit zo'n vakantieprobleem in mijn leven gezien!

Trouwens, over deze drie vensters die je in de bovenstaande schermafbeelding ziet. Het venster Samenvattingsinstellingen loopt zo nu en dan vast. Bovendien kan het alleen worden uitgeschakeld door het proces in Taakbeheer uit te schakelen, er is geen andere manier. En u kunt het synchronisatievenster alleen sluiten door u af te melden bij het systeem.

Als u op "Nee" klikt, blijft het venster altijd openhangen. Ondanks het feit dat de browser zelf daarentegen af ​​en toe spontaan wordt uitgeschakeld. En wat grappig is: de browser wordt uitgeschakeld, maar het bevroren samenvattingsvenster en het geopende synchronisatievenster niet, en ze blijven daar onbeheerd hangen, achtergelaten door de browser, totdat je ze uitschakelt in Taakbeheer. Betoverende foutjes!

Het zou echter verkeerd zijn om de positieve aspecten van de browser niet op te sommen.

Ten eerste is dit de anonieme surfmodus. U schakelt deze modus in de instellingen in en de browser gebruikt geen cache, cookies of registreert uw browsegeschiedenis. Er zijn browsers die alleen in deze modus werken, bijvoorbeeld Browzar, wat soms noodzakelijk is, maar over het algemeen uiterst onhandig. En de mogelijkheid om snel verbinding te maken en deze modus uit te schakelen is een groot pluspunt voor de browser.

Ten tweede kunt u met YRC Weblink uw standaardzoekmachine kiezen. Je moet echter kiezen uit een vrij specifieke lijst:

Het adres van de zoekmachine kan echter ook handmatig worden opgegeven door op de knop Nieuw definiëren te klikken (het is niet zichtbaar in de schermafbeelding, het staat onder de lijst).

Nou ja, het laatste, maar zeer belangrijke pluspunt: YRC Weblink laadt het systeem nauwelijks! Ter vergelijking: ik opende er 10 tabbladen in en opende 10 tabbladen met dezelfde adressen in de Yandex-browser (de leider onder browsers bij het laden van het systeem) en dit is de foto die we kregen.

Yandex-browser:

Het is niet moeilijk te raden dat YRC Weblink in deze zin praktisch ongeëvenaard is, en wel op een goede manier.

SAMENVATTING . Als alle ideeën die de makers in deze browser probeerden te implementeren correct waren uitgevoerd, zou er geen prijs voor zijn, YRC Weblink zou aanspraak kunnen maken op de titel van de beste, of op zijn minst een van de beste browsers. Maar met de tekortkomingen die erin worden geconstateerd, komt het niet eens in aanmerking voor een “C”. Ik geef het een beoordeling van 3-.

Na het testen verwijder ik de browser - het is absoluut niet nodig om zo'n programma met fouten op je computer te hebben. Welnu, we wachten op verdere stappen van YRC Group Inc. Indiase programmeurs zullen alle tekortkomingen kunnen wegnemen en een echt werkende versie van de browser kunnen uitbrengen, met eer en lof voor hen. Als ze falen, zal er weer een doodgeboren browser ter wereld zijn.

Toegangspunt tot Joomla! component is voor de meeste componenten vergelijkbaar. Voor dit voorbeeld gebruiken we een van de kerncomponenten van Joomla: Weblinks. Het eerste bestand dat in de front-end wordt uitgevoerd: …/components/com_weblinks/weblinks.php .

Eerst zien we een veiligheidscontrole die ervoor moet zorgen dat niemand deze pagina rechtstreeks kan bellen. Dit is de standaard die in al je php-bestanden moet worden gebruikt (hoewel er een paar uitzonderingen zijn):

We controleren de queryreeks om te zien of er een specifieke controllernaam is verzonden. Als dat zo is, zorgen we ervoor dat we het vereiste bestand in de controllers-directory kunnen laden:

Nu instantiëren we onze controllerklasse met de naam die we hierboven hebben gedefinieerd:

Zodra de taak is voltooid, voeren we indien nodig een omleiding uit:

De generieke (specifieke) controller voor de linkscomponent bevindt zich hier: .../components/com_weblinks/controller.php.
Deze hele klasse definieert een weergavemethode, wat de standaardmethode is die wordt gebruikt, tenzij de gebruiker een andere taak opgeeft.

Bij deze methode stellen we de standaardweergave zo in dat categorieën worden weergegeven, tenzij een andere weergave is doorgegeven als parameter voor de queryreeks. Als de vereiste weergave een weblink is, verhogen we de linkweergaveteller. Vervolgens stellen we de waarde van de viewvariabele in en roepen de diplay-methode van onze bovenliggende JController-klasse aan.
Het is de moeite waard om speciale aandacht te besteden aan de aanroep van de getModel-methode. Het laadt het vereiste model voor de component. In dit voorbeeld laadt deze methode het weblinkmodel dat zich hier bevindt: .../components/com_weblinks/models/weblink.php.
Hier zullen we afspreken dat we niet om een ​​specifieke weergave hebben gevraagd en dat onze weergave daarom in categorieën zal worden ingedeeld.
Vervolgens openen we de view-klasse.

Omdat we ervan uitgaan dat we een categorieweergave willen, is dit het volgende bestand dat wordt uitgevoerd: .../components/com_weblinks/views/categories/view.html.php

Nogmaals, dit is een heel eenvoudige klasse met één weergavemethode. De meeste logica hier is specifiek voor de linkcomponent, maar als je goed kijkt, kun je functionaliteit vinden die in de meeste componentweergaveklassen wordt gebruikt. Aan het einde van de weergavemethode roept deze klasse de bovenliggende weergavemethode (JView) aan, waarbij de naam wordt doorgegeven van de sjabloon die moet worden weergegeven. Als de naam van het weergavesjabloon niet wordt doorgegeven, wordt het "standaard" sjabloon gebruikt.
En ten slotte openen we de sjabloonklasse.

Laten we afspreken dat er geen specifieke sjabloonnaam is doorgegeven, zodat de standaardsjabloon wordt gebruikt. In dit geval wordt rekening gehouden met het volgende bestand: .../components/com_weblinks/views/categories/tmpl/default.php
-> escape ($dit -> params -> get ("page_title" ) ); ?>

• ( )

Een groot deel van de logica hier is specifiek voor de component die wordt uitgevoerd. Je kunt ook aan de code zien dat dit bestand alle HTML bevat, gemengd met PHP - dit zijn de kenmerken en het doel ervan.

Verschillende andere bestandstypen die u mogelijk in componenten aantreft:

• Helpers - componenten gebruiken vaak een helper.php-bestand of een helpers-map met veel bestanden. Deze bestanden bevatten doorgaans alleen de algemene functionaliteit voor de component.
• Assets lijkt een verzamelmap te zijn voor andere bestanden die in de component zijn opgenomen.
• router.php - dit bestand wordt gebruikt, wanneer de SEF URL-instelling is ingeschakeld, om de URL in beide richtingen te vertalen (naar een voor mensen leesbare URL met aliassen en naar de Joomla-systeemweergave met parameters).
• xml-bestanden - ze definiëren meestal parameters en andere informatie over de component en het overzicht ervan. Ze worden bijvoorbeeld gebruikt bij het maken van componentmenu-items.
• index.html - Het is een goede gewoonte om in al uw mappen een leeg index.html-bestand te hebben. Dit is zo'n passieve beveiligingsmaatregel.
• css/images/js - Mappen die verschillende bestanden bevatten om het ontwerp en de functionaliteit aan de clientzijde (in de browser) te implementeren.

Laten we beginnen met kijken naar de componenten door te kijken hoe de basiscomponent Weblinks werkt in het beheerdersgedeelte van een website. Dit onderdeel, dat typisch is voor dit deel van de website, lijkt sterk op de andere componenten die zijn ontworpen om artikelen, gebruikers, modules, enz. te beheren.

De programmabestanden voor dit onderdeel staan ​​hieronder vermeld. Al deze bestanden bevinden zich in de map beheerder/components/com_weblinks. In de rest van dit hoofdstuk wordt naar alle bestandsnamen van de Weblinks-componenten verwezen ten opzichte van deze startmap, tenzij anders aangegeven. De meeste bestanden zijn georganiseerd volgens het MVC-patroon. Concreet bevinden alle weergavebestanden zich in de submap views, en alle hoofdmodel- en controllerbestanden bevinden zich respectievelijk in de submappen models en controllers. Ze worden ook aangevuld met installatie-, configuratie- en hulpbestanden.

Bestanden van het administratieve gedeelte van de component Weblinks, behalve index.html-bestanden

• controllers/weblink.php - Hoofdcontroller voor bewerken Enkele weblinkcontroller
• controllers/weblinks.php - Hoofdcontroller voor het compileren van de Controller en het weergeven van een lijst met weblinks op het Weblinks Manager-scherm
• helpers/weblinks.php - Biedt verschillende methoden die worden gebruikt in controllers en weergaven
• models/fields/ordering.php - JformField-model dat de bestelkolom voor weblinks weergeeft op het Weblinks Manager-scherm
• models/forms/weblink.xml - XML-bestand gebruikt in de klasse Jform-Model Field om een ​​formulier op te maken met invoervelden en weblinks op het scherm te bewerken
• models/weblink.php - Model voor een enkel schermformulier Weblinkmodel
• models/weblinks.php - Model voor het managerschermformulier Model van weblinks
• sql/install.mysql.utf8.sql - SQL-bestand om een ​​tabel met weblinks te maken tijdens de installatie
• sql/uninstall.mysql.ut8.sql - SQL-bestand om de weblinktabel tijdens de installatie te verwijderen
• table/weblink.php - Biedt de klasse Model
• views/weblink/tmpl/edit_metadata.php - Bronlay-outbestand voor het bewerken van metagegevens van weblinks

Administratief gedeelte van de component Weblinks

• views/weblink/tmpl/edit_params.php - Bronlay-outbestand voor het bewerken van selectieopties voor afzonderlijke weblinks
• views/weblink/tmpl/edit.php - Bronlay-outbestand voor het bewerken van een weblink
• views/view.html.php - Hoofdweergaveklasse voor het weergeven van een enkele weblink in HTML-formaat. Bronlay-outbestand voor weblinkmanager
• views/weblinks/view.html.php - Hoofdweergaveklasse voor het weergeven van weblinks in HTML-formaat rechtstreeks op het Weblinks Manager-scherm
• access.xml - XML-bestand met een lijst met acties voor een toegangscontrolelijstsysteem (ACL).
• config.xml - XML-bestand met een lijst met opties voor het selecteren van de configuratie van de component
• controller.php - Hoofdcontrollerklasse
• weblinks.php - Ingangspunt voor het verzoek
• weblinks.xml - XML-bestand dat wordt gebruikt om het installatieproces te beheren

Deze maand willen buggravers ons niet verwennen met nieuwe spraakmakende exploits in populaire applicaties. Natuurlijk zijn er veel adviezen gepubliceerd in producten van bekende bedrijven, maar slechts weinig daarvan bevatten leesbare PoC-codes. In onze review heb ik geprobeerd de meest significante en volledige kwetsbaarheden te verzamelen die onlangs zijn beschreven, dus leun achterover en lees veel.

Op 3 maart ontdekte een zekere Adam Ivanyuk een interessante functie in de PHP-interpreter, die HEAD-verzoeken niet helemaal correct verwerkt. De onderzoeker noemde deze kwetsbaarheid “HTTP HEAD-methodetruc in php-scripts.”

Veel programmeurs ontwerpen hun PHP-scripts in de hoop dat alle instructies die erin zijn geschreven succesvol zullen worden uitgevoerd zonder ergens in het midden te breken (vooral in korte scripts). Dit is wat er gebeurt als het script door de eindgebruiker wordt opgevraagd met behulp van de GET-, POST-, PUT-methoden.

Maar u moet weten dat er andere HTTP-methoden zijn, bijvoorbeeld HEAD. Juist bij het verwerken van deze methode in PHP kan er een veiligheidslek ontstaan.

Laten we eens kijken naar een van de tolkbronnen: ./main/SAPI.c, regel 315:

if (SG(request_info).request_method &&
!strcmp(SG(request_info).request_method, "HEAD"))
{
SG(request_info).headers_only = 1;
...

Wanneer er gegevens binnenkomen, wordt de functie php_ub_body_write uitgevoerd. Kijk vervolgens naar main/output.c, regel 699:

if (SG(request_info).headers_only) (
if(SG(headers_sent))
{
retour 0;
}
php_header(TSRMLS_C);
zend_bailout();
}

Hier kunt u zien dat de eerste keer dat het op het scherm wordt afgedrukt en bij gebruik van de HEAD-methode, de functie zend_bailout het script verbreekt.

Laten we nu dit script openen met behulp van de HEAD-methode:

Zoals je zou verwachten, zal ons gastenboek de uitvoering ervan stoppen bij de regel “echo $data;”, dus het bestand book.txt wordt eenvoudigweg op nul gezet.
Dit voorbeeld is nogal destructief van aard. In het tweede voorbeeld kunnen we de autorisatie in het primitieve beheerderspaneel omzeilen:

In dit script wordt bij het inloggen via de gebruikelijke methoden een administratieve variabele in de sessie ingesteld. Als de gebruiker vervolgens een onjuist wachtwoord invoert, wordt deze variabele opnieuw ingesteld en wordt de gebruiker geen beheerder.

Als we via HEAD toegang krijgen tot het beheerderspaneel, wordt de uitvoering ervan onderbroken bij het stukje code met “echo”, zodat de administratieve variabele niet wordt gereset en we veilig door het gesloten deel van de applicatie kunnen dwalen. Het ding om in gedachten te houden is dat bij de meeste webservers de uitvoerbufferwaarde is ingesteld op 4096 bytes, dus in een werkend voorbeeld hebben we mogelijk de string ‘Een lange string bevat ongeveer 4090 tekens’ nodig.

• PHP

  Hier bevat de array $check onze POST-gegevens, en de variabele $locked is een geserialiseerde string die wordt versluierd met behulp van de functie str_rot13(), die volledig onder onze controle staat.

  Op dit punt is het de moeite waard een kleine uitweiding te maken voor degenen die de overeenkomstige artikelen in ][ niet hebben gelezen, en kort te praten over de bug die voorkomt in de magische methoden van PHP. Dus in PHP versie 5 verscheen het basisconcept van OOP-programmeren: constructor en destructor. Een constructor wordt geïmplementeerd met behulp van de "__construct" -methode en een destructor wordt geïmplementeerd met behulp van de "__destruct" -methode. Na voltooiing van zijn werk en wanneer het wordt aangeroepen via de functie unserialize(), voert elk object zijn eigen __ destruct-methode uit, als deze in de code is geschreven.

  Laten we nu teruggaan naar ons raamwerk en kijken naar de App-klassedestructor uit het bestand ./libs/configure.php:

  functie __destruct()
  {
  if ($dit->__cache)
  {
  $core = App::core("taart");
  unset($this->__paden);
  Cache::write("dir_map", array_fi lter($this->__paths),
  "taart_kern");
  Cache::write("bestand_map", array_fi lter($this->__map),
  "taart_kern");
  Cache::write("object_map", $this->__objects,
  "taart_kern");
  }
  }

  Uit de bovenstaande code kun je zien dat deze methode kan worden aangetast door willekeurige waarden naar het Cache-object te schrijven. De meest interessante sleutel om te kraken is 'file_map'. Het beheert de verbindingen tussen klassen en de bijbehorende PHP-bestanden, en wordt ook gebruikt om extra klassen te laden tijdens de uitvoering van scripts.

  De daadwerkelijke code voor het laden van klassen is iets complexer, maar het komt allemaal neer op de volgende code van de __load-methode in de App-klasse:

  Bingo! Door de variabele $file te vervangen, kunnen we onze eigen PHP-code toevoegen! Bovendien zal dit een echte Remote File Inclusion-bug zijn - we hebben dus geen extra trucjes nodig bij het uploaden van lokale bestanden naar de server. De auteur van het gevonden beveiligingslek biedt echter een LFI-optie om dit gat te misbruiken, omdat CakePHP een op bestanden gebaseerde lokale cache gebruikt, die zich in geserialiseerde vorm bevindt in een map die bekend is bij de aanvaller.

  Uitbuiten

  Als een kleine PoC voor het genereren van een giftige geserialiseerde string biedt felix de volgende code:

  Natuurlijk moet je eerst de benodigde klassen van CakePHP opnemen. Er is ook een volledig functionele Python-exploit, die je kunt vinden op malloc.im/burnedcake.py.

  Deze exploit zou moeten werken in elke applicatie die op CakePHP is gebouwd, waarbij gebruik wordt gemaakt van POST-formulieren met beveiligingstokens, en waarin de standaardlocatie van de cachebestanden niet is gewijzigd. Standaard geeft de exploit de databaseconfiguratie weer; andere handige functies kunnen eenvoudig worden toegevoegd door de ingebouwde PHP-payload te wijzigen.

  Doelstellingen
  • CakePHP getState("fi lter_order_dir");
    $fi lter_order = JFilterInput::clean($fi lter_order, "cmd");
    $filter_order_dir =
    JFilterInput::clean($fi lter_order_dir, "woord");
    // We hebben een lijst van allemaal nodig
    // weblinks in de opgegeven categorie
    $query = "SELECTEER *" .
    "VAN #__weblinks" .
    "WAAR catid = ". (int) $dit->_id.
    "EN gepubliceerd = 1" .
    "EN gearchiveerd = 0".
    "BESTEL DOOR". $filter_order "".
    $filter_order_dir .", bestellen";
    retourneer $query;
    }

    Hier kun je zien dat de variabelen $filter_order en $filter_order_dir niet worden gecontroleerd op strikte naleving van SQL-instructies; de controle wordt alleen uitgevoerd met behulp van de standaard opschoningsmethode uit de klasse JFilterInput: