De component wordt gebruikt om het machtigingsformulier weer te geven. Meestal gebruikt in een website-ontwerpsjabloon. De component is standaard en inbegrepen in de moduledistributie. In de visuele editor bevindt de component zich langs het pad: Hulpprogramma's > Gebruiker.

In de visuele editor bevindt de component zich langs het pad: Systeemwerkset > Gebruiker > Autorisatieformulier.

Voorbeeld van het aanroepen van de component system.auth.form

Beschrijving van parameters Wachtwoordherstelmechanisme (ter referentie)

Als de gebruiker wachtwoordherstel heeft aangevraagd, vindt het herstel plaats volgens het volgende mechanisme:

De gebruiker klikt op Wachtwoord vergeten?

in het machtigingsformulier.

Er wordt een willekeurige reeks van 32 tekens gegenereerd, waarbij rekening wordt gehouden met een geheim dat alleen bekend is bij de server.

• Het resultaat wordt vastgelegd in de database en per e-mail verzonden. Link zoals: http://site.ru/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=3farde09fay52547f11c68bf17d95760&USER_LOGIN=market, waar:
• http://site.ru/bitrix/admin/index.php - pad naar de autorisatie- of wachtwoordwijzigingspagina;
• change_password=yes - actie voor het wijzigen van het wachtwoord;
• lang=ru taalidentificatie;

  USER_CHECKWORD=- controlereeks voor het wijzigen van het wachtwoord, 32 tekens. De tekenreeks maakt gebruik van tekens. beschikbaar voor md5: .

• Wanneer u het wachtwoord wijzigt, voert u in het controleregelverzoek alleen de controleregel in, zonder USER_CHECKWORD= !

&USER_LOGIN=market - indicatie voor welke gebruiker het wachtwoord wordt gewijzigd.

Bij het vergelijken van de controleregel uit het formulier met wat in de database is vastgelegd, wordt rekening gehouden met de vervaltijd die is opgegeven in het groepsbeveiligingsbeleid.

Opmerking: In het wachtwoordherstelformulier wordt aanbevolen om CAPTCHA te gebruiken - het veld Gebruik CAPTCHA bij het herstellen van het wachtwoord in de instellingen van de hoofdmodule.

"Bitrix", 2001-2019, "1C-Bitrix", 2019

In de laatste les hebben we uitgezocht uit welke blokken het reissjabloon zal bestaan, zodat we aan de slag kunnen. Laten we eerst twee mappen maken:

afbeeldingen - deze map bevat alle grafische bestanden die zijn gebruikt om de sjabloon te ontwerpen. Omdat We hebben nog geen ontwerpontwikkelingen, plaats dan een grafisch bestand in deze map, anders zal Joomla de sjabloon niet installeren en een foutmelding geven als de map leeg is.

css - deze map bevat trapsgewijze stijlbladbestanden. Laten we er eerst een leeg template.css-bestand in plaatsen, met behulp waarvan we verschillende ontwerpstijlen aan de site-elementen zullen toewijzen.

Vervolgens kunt u beginnen met het maken van het hoofdbestand index.php, dat de visuele indeling van site-elementen bepaalt en het Joomla CMS vertelt in welk blok verschillende componenten en modules moeten worden geplaatst. Het bestand is een combinatie van PHP en HTML.

Ik gebruik altijd alleen Macromedia Dreamweaver bij het schrijven van code. Een uitstekend programma, ik raad het ten zeerste aan voor beginners, omdat... Als u een fout heeft gemaakt tijdens het werken aan de code, zal het programma uw fout zeker benadrukken.

Op de site vindt u een tutorial voor Macromedia Dreamweaver. Als u websites gaat ontwikkelen, moet u dit programma in ieder geval op het beginniveau beheersen om sjablooncodes foutloos te kunnen bewerken.

De positionering van pagina-elementen (blokken) gebeurt met behulp van HTML-code; we zullen specifiek DIV-tags gebruiken. Maar de manier waarop onze site zal werken op de Joomla-engine, d.w.z. het zal dynamisch zijn, dan zul je ook de PHP-taal moeten gebruiken. Met zijn hulp zullen we bepalen in welke blokken de posities voor uitvoerende modules zich zullen bevinden, en hoe deze posities zullen worden genoemd, of de blokken zullen worden samengevouwen of niet. We verbinden stijlbladen van externe bestanden, de taal van de inhoud, stellen in hoe de sitegrootte zal veranderen, enz.

index.php

Bestandskop

De bestandskop bestaat uit verschillende delen. Het eerste deel van de PHP-headercode is om ervoor te zorgen dat het bestand om veiligheidsredenen niet rechtstreeks toegankelijk is.

< ?php
gedefinieerd ("_JEXEC" ) of die ;
JHtml::_("gedrag.framework" , true ) ;
$app = JFactory::getApplication() ;
?>
< ?php echo "< ?" ; ?>xml-versie = "1.0" encoding = "< ?php echo $this - >_charset ?> " ?>

DOCTYPE is een zeer belangrijke parameter op basis waarvan de browser beslist hoe deze pagina wordt weergegeven en hoe de CSS wordt geïnterpreteerd.

< ! DOCTYPE html PUBLIC "- / / W3C/ / DTD XHTML 1.0 Strict/ / EN" "http:/ / www.w3.org/ TR/ xhtml1/ DTD/ xhtml1- strict.dtd" >

Met het volgende fragment wordt de geïnstalleerde taal opgehaald uit de algemene configuratie.

< html xmlns= "http:/ / www.w3.org/ 1999/ xhtml" xml:lang= "< ?php echo $this - >taal; ?> " lang = "< ?php echo $this - >taal; ?> " dir = "< ?php echo $this - >richting; ?> ">

Het volgende is een stukje code dat aanvullende headerinformatie bevat die is ingesteld in de globale configuratie. U kunt deze informatie bekijken door naar de broncode van een webpagina te kijken. In het bijzonder zijn dit metatags waarvan u al op de hoogte bent.

< head>
< jdoc:include type= "head" / >

De volgende kopregels bevatten links naar de belangrijkste Joomla CSS-stijlen.

< link rel= "stylesheet" href= "< ?php echo $this - >baseurl ?> / templates/ systeem / css/ systeem .css" type= "text/ css" / >
< link rel= "stylesheet" href= "< ?php echo $this - >baseurl ?> / templates/ systeem / css/ general.css" type="text/ css" / >

Om sjabloonontwerpstijlen te gebruiken, linken we naar een bestand met trapsgewijze stijlbladen template.css, dat zich in de CSS-map bevindt. Het maakt niet uit dat dit bestand voorlopig leeg is, het belangrijkste is om het aan te sluiten, we zullen het ontwerp later behandelen als we de sjabloon op Joomla installeren. Dit maakt het gemakkelijker om het resultaat te observeren.

< link rel= "stylesheet" href= "< ?php echo $this - >baseurl ?> /sjablonen/< ?php echo $this - >sjabloon ?> / css/ template.css" type= "text/ css" / >

Met het volgende codefragment kunnen we de linker- of rechterkolom samenvouwen als er zich geen modules op de linker- en rechterpositie bevinden. Als beide kolommen zijn samengevouwen, neemt de inhoud 100% van de paginabreedte in beslag. Als er slechts één kolom is opgenomen, neemt de inhoud 80% in beslag. Als twee kolommen zijn ingeschakeld, neemt de inhoud 60% van de paginabreedte in beslag.

< ?php
if ($this -> countModules("left and right" ) = = 0) $contentwidth = "100" ;
if ($this -> countModules("left or right" ) = = 1) $contentwidth = "80" ;
if ($this -> countModules("left and right" ) = = 1) $contentwidth = "60" ;
?>

Kop wordt gesloten

< / head>

< body>

Het “pagina”-blok bevat het ontwerp van alleen de sitepagina, die 950px breed zal zijn.

< div id= "page" >

Het "bovenste" blok bevindt zich helemaal bovenaan de pagina en bevat twee blokken "logo" en "gebruiker1".

< div id= "top" >

In de “logo” bokeh plaatsen wij een grafisch bestand van het logo; dit wordt gespecificeerd in de stylesheets. Maar we schrijven de automatische weergave van de sitenaam in het index.php-bestand en plaatsen de naam in de H1-tag, wat erg belangrijk is voor zoekmachineoptimalisatie.

< div id= "logo" >
< h1> < ?php echo $app - >getCfg("sitenaam" ); ?>< / h1>
< / div>

Laten we de positie “user1” definiëren in het blok met dezelfde naam om de sitezoekmodule weer te geven.

< div id= "user1" >
< jdoc:include type= "modules" name= "user1" style= "xhtml" / >
< / div>
< / div> < ! - - конец блока top - - >

Uitvoer van de horizontale menumodule in het “user2”-blok in de “user2”-positie. Het blok zal instorten als er geen module op die positie staat.

< ?php if ($this - >countModules("user2" ) : ?>
< div id= "user2 " >
< jdoc:include type= "modules" name= "user2" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Vervolgens komt het site-headerblok. Daarin zullen we de “header”-positie definiëren voor het weergeven van modules. Het blok zal instorten als er geen module op die positie staat. Ik heb opzettelijk de mogelijkheden van dit blok uitgebreid om er niet alleen de headerafbeelding in te kunnen plaatsen, maar ook afbeeldingsrotators.

< ?php if ($this - >countModules("header " ) ): ?>
< div id= "header " >
< jdoc:include type= "modules" name= "header " style= "xhtml" / >
< / div>
< ?php endif ; ?>

In het blok “user3” definiëren we de positie “user3” voor het uitvoeren van modules.

Het blok zal instorten als er geen module-uitvoer is op deze positie "user3".

< ?php if ($this - >countModules("user3" ) : ?>
< div id= "user3" >
< jdoc:include type= "modules" name= "user3" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Er gaat een blok van de linkerkolom open, dat instort als er geen modules in de “linker” positie staan.

< ?php if ($this - >countModules("left" ) ) : ?>
< div id= "left" >
< jdoc:include type= "modules" name= "left" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Het belangrijkste inhoudsblok wordt geopend, dat 100% van de paginabreedte, 80% en 60% kan beslaan, afhankelijk van het aantal opgenomen kolommen.

< div id= "content< ?php echo $contentwidth ; ?> " >

Berichten weergeven in componenten

< jdoc:include type= "message" / >

Inhoud inhoud uitvoeren.

< jdoc:include type= "component" style= "xhtml" / >
< / div> < ! - - конец блока контента- - >

Er gaat een blok van de rechterkolom open, dat instort als er geen modules op de “juiste” positie staan.

< ?php if ($this - >countModules("right" ) : ?>
< div id= "rigth" >
< jdoc:include type= "modules" name= "right" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Uitvoer van het “voettekst”-blok, ontworpen om de “HTML-code”-module met copyrightinformatie weer te geven. U kunt hier ook een horizontaal menu of een inhoudspresentatiemodule plaatsen. Het blok wordt samengevouwen als er meer dan één module in deze “voettekst”-positie wordt weergegeven

< ?php if ($this - >countModules("voettekst") ) : ?>
< div id= "footer" >
< jdoc:include type= "modules" name= "footer" style= "xhtml" / >
< / div>
< ?php endif ; ?>

Het sitepaginablok “pagina”, de hoofdtekst en alle code zijn gesloten.

< / div> < ! - - конец блока page- - >
< / body> < ! - - конец блока body - - >
< / html> < ! - - конец кода- - >

We hebben een compleet index.php-bestand gemaakt. Nu weet u welke commando's worden gebruikt en in welke volgorde de sjabloonblokken worden weergegeven.

LET OP: Om de sjablooncode te kunnen lezen vanuit het joomla admin-paneel, moet het index.php-bestand worden geopend in de AkelPad-editor en worden opgeslagen in UTF-8-codering, terwijl het selectievakje BOM is uitgeschakeld. Als u het Macromedia Dreamweaver-programma hebt gebruikt om met het bestand te werken, moet u in het bovenste menu "Bewerken"> "Pagina-eigenschappen" selecteren en de documentcodering Unicode (utf-8) selecteren en het vinkje bij "Enable Unicode signatures (BOM)" uitschakelen. )”. Ik raad u echter ten zeerste aan om de code vanuit het Joomla-beheerpaneel niet te bewerken, als u iets verprutst - er is geen weg meer terug, in tegenstelling tot het Macromedia Dreamweaver-programma, waar u de aangebrachte wijzigingen altijd ongedaan kunt maken.

Het ontwerp van de blokken zelf wordt beschreven in template.css. Maar we zullen stijlbladen configureren na het installeren van de sjabloon op Joomla 3 (joomla 2.5), en hiervoor moeten we

Vandaag zullen we kijken naar de exploitatie van een kritieke 1-day kwetsbaarheid in het populaire CMS Joomla, die eind oktober op internet explodeerde. We zullen het hebben over kwetsbaarheden met de nummers CVE-2016-8869, CVE-2016-8870 en CVE-2016-9081. Alle drie komen uit één stukje code dat vijf jaar lang in de diepten van het raamwerk wegkwijnde, wachtend in de coulissen, om vervolgens los te breken en chaos, gehackte sites en de tranen van onschuldige gebruikers van deze Joomla met zich mee te brengen. Alleen de meest dappere en moedige ontwikkelaars, wier ogen rood zijn van het licht van de monitoren en wier toetsenborden bezaaid zijn met broodkruimels, waren in staat de woedende boze geesten uit te dagen en hun hoofd op het altaar van de fixes te leggen.

WAARSCHUWING Alle informatie wordt uitsluitend ter informatie verstrekt. Noch de redactie, noch de auteur zijn verantwoordelijk voor eventuele schade veroorzaakt door de materialen van dit artikel. Waar het allemaal begon

Op 6 oktober 2016 creëerde Demis Palma een onderwerp op Stack Exchange waarin hij vroeg: waarom zijn er in Joomla versie 3.6 eigenlijk twee methoden voor het registreren van gebruikers met dezelfde naam register()? De eerste bevindt zich in de UsersControllerRegistration-controller en de tweede bevindt zich in de UsersControllerUser-controller. Damis wilde weten of de methode UsersControllerUser::register() ergens werd gebruikt, of dat het slechts een evolutionair anachronisme was dat was overgebleven uit de oude logica. Zijn zorg was dat zelfs als deze methode door geen enkele weergave wordt gebruikt, deze kan worden aangeroepen door een vervaardigde query. Waarop ik een reactie kreeg van een ontwikkelaar onder de bijnaam itoctopus, die bevestigde: het probleem bestaat echt. En stuurde een rapport naar de Joomla-ontwikkelaars.

Toen ontwikkelden de gebeurtenissen zich het snelst. Op 18 oktober accepteerden Joomla-ontwikkelaars het rapport van Damis, die tegen die tijd een PoC had opgesteld die gebruikersregistratie mogelijk zou maken. Hij publiceerde een notitie op zijn website, waarin hij in algemene termen sprak over het probleem dat hij ontdekte en zijn gedachten hierover. Op dezelfde dag wordt een nieuwe versie van Joomla 3.6.3 uitgebracht, die nog steeds kwetsbare code bevat.

Hierna draait Davide Tampellini de bug zo om dat er geen eenvoudige gebruiker, maar een beheerder wordt geregistreerd. En op 21 oktober arriveert er een nieuwe zaak bij het Joomla-beveiligingsteam. Er wordt al gesproken over het vergroten van privileges. Op dezelfde dag verschijnt er op de Joomla-website een aankondiging dat op dinsdag 25 oktober de volgende versie met serienummer 3.6.3 uitkomt, waarmee een kritieke kwetsbaarheid in de systeemkernel wordt verholpen.

25 oktober Joomla Security Strike Team vindt het nieuwste probleem dat is veroorzaakt door het stukje code dat door Damis is ontdekt. Vervolgens wordt een commit gedateerd 21 oktober met de onopvallende naam Prepare 3.6.4 Stable Release naar de hoofdtak van de officiële Joomla-repository gepusht, die de ongelukkige bug repareert.

Na deze release sluiten talloze geïnteresseerde individuen zich aan bij de ontwikkelaarsgemeenschap - ze beginnen de kwetsbaarheid te promoten en exploits voor te bereiden.

Op 27 oktober uploadt onderzoeker Harry Roberts een kant-en-klare exploit naar de Xiphos Research repository die een PHP-bestand kan uploaden naar een server met een kwetsbaar CMS.

Details

Nou, de achtergrond is voorbij, laten we verder gaan met het meest interessante deel: analyse van de kwetsbaarheid. Ik heb Joomla 3.6.3 als testversie geïnstalleerd, dus alle regelnummers zijn relevant voor deze versie. En alle paden naar de bestanden die u hieronder ziet, worden aangegeven ten opzichte van de root van het geïnstalleerde CMS.

Dankzij de ontdekking van Damis Palma weten we dat er twee methoden zijn die gebruikersregistratie in het systeem uitvoeren. De eerste wordt gebruikt door het CMS en bevindt zich in het bestand /components/com_users/controllers/registration.php:108. De tweede (degene die we moeten oproepen) bevindt zich in /components/com_users/controllers/user.php:293. Laten we het eens nader bekijken.

286: /** 287: * Methode om een ​​gebruiker te registreren. 288: * 289: * @return boolean 290: * 291: * @since 1.6 292: */ 293: public function register() 294: ( 295: JSession::checkToken("post") of jexit(JText::_ ("JINVALID_TOKEN")); ... 300: // Haal de formuliergegevens op: $data = $this->input->post->get("user", array(), "array"); 315: $return = $model->validate($form, $data); 316: 317: // Controleer op fouten. Voltooi de registratie 346: $return = $model->register($data);

Hier liet ik alleen interessante regels achter. De volledige versie van de kwetsbare methode kan worden bekeken in de Joomla-repository.

Laten we eens kijken wat er gebeurt tijdens de normale gebruikersregistratie: welke gegevens worden verzonden en hoe deze worden verwerkt. Als gebruikersregistratie is ingeschakeld in de instellingen, kunt u het formulier vinden op http://joomla.local/index.php/component/users/?view=registration.

Een legitiem gebruikersregistratieverzoek ziet eruit als de volgende schermafbeelding.

De component com_users is verantwoordelijk voor het werken met gebruikers. Let op de taakparameter in de aanvraag. Het heeft het formaat $controller.$method . Laten we eens kijken naar de bestandsstructuur.

De namen van de scripts in de map controllers komen overeen met de namen van de opgeroepen controllers. Omdat ons verzoek nu $controller = "registration" heeft, zullen het registratie.php-bestand en de bijbehorende register()-methode worden aangeroepen.

Let op, vraag: hoe kan de registratieverwerking naar een kwetsbare plaats in de code worden overgebracht? Je raadt het waarschijnlijk al. De namen van de kwetsbare en echte methoden zijn hetzelfde (register), dus we hoeven alleen de naam van de opgeroepen controller te wijzigen. Waar bevindt onze kwetsbare controller zich? Dat klopt, in het user.php-bestand. Het blijkt $controller = "user" . Als we alles samenvoegen, krijgen we task = user.register . Nu wordt het registratieverzoek verwerkt volgens de methode die we nodig hebben.

Het tweede dat we moeten doen is de gegevens in het juiste formaat verzenden. Alles is hier eenvoudig. Legitieme register() verwacht van ons een array genaamd jform , waarin we registratiegegevens doorgeven - naam, login, wachtwoord, e-mail (zie screenshot met het verzoek).

• /components/com_users/controllers/registration.php: 124: // Haal de gebruikersgegevens op.

125: $requestData = $this->input->post->get("jform", array(), "array");

• Onze klant haalt deze gegevens uit een array genaamd user.

/components/com_users/controllers/user.php: 301: // Haal de formuliergegevens op.

302: $data = $this->input->post->get("gebruiker", array(), "array");

• Daarom veranderen we de namen van alle parameters in de aanvraag van jfrom in user .

Onze derde stap is het vinden van een geldig CSRF-token, want zonder dit is er geen registratie mogelijk.

/components/com_users/controllers/user.php: 296: JSession::checkToken("post") of jexit(JText::_("JINVALID_TOKEN"));

Het ziet eruit als een MD5-hash en je kunt het bijvoorbeeld uit het autorisatieformulier op de site /index.php/component/users/?view=login halen.

• Nu kunt u gebruikers aanmaken via de gewenste methode. Als alles werkte: gefeliciteerd. U heeft zojuist misbruik gemaakt van de CVE-2016-8870-kwetsbaarheid voor ontbrekende toestemming voor het registreren van nieuwe gebruikers.

Zo ziet het eruit in de “werkende” register()-methode van de UsersControllerRegistration-controller:

• /components/com_users/controllers/registration.php: 113: // Als registratie is uitgeschakeld - Omleiding naar inlogpagina.

114: if (JComponentHelper::getParams("com_users")->get("allowUserRegistration") == 0) 115: ( 116: $this->setRedirect(JRoute::_("index.php?option=com_users&view= login", false)); 117: 118: retourneert false; 119: )

En dus in kwetsbaar:

/components/com_users/controllers/user.php:

Ja, absoluut niet.

Je kunt lang argumenteren waarom sommige mensen graag de vruchten van andermans werk verpesten en vernietigen, maar op de een of andere manier is dit een feit dat ook relevant is voor de virtuele wereld. Zelfs aan het begin van de thuis-pc, d.w.z. Toen iedereen er toegang toe kreeg, begon deze plaag.

Het eerste virus werd geschreven, de website werd voor het eerst gehackt... nu zal dit niemand verbazen. Velen zijn al gewend aan het zien van opschriften als “Ik was hier een super-duper hacker” en andere uitingen van computervandalisme van tijd tot tijd.

De meeste van deze aanvallen vinden plaats als gevolg van het misbruiken van gaten in serverscripts. Het gaat over het dichten van dezelfde mazen in de wet voor hackers waar dit artikel het over zal hebben.

Dus, zoals gezegd, kan een hacker toegang krijgen tot de site via serverscripts (er zijn natuurlijk nog veel meer mogelijkheden, bijvoorbeeld het stelen van een wachtwoord - met een Trojaans paard, een sniffer of zelfs schaamteloos vanaf de computer van de gebruiker, maar dat is een apart onderwerp). Waarom serverversies? Ja, want met die van de klant - die worden uitgevoerd op de machine van de bezoeker van de site - kan hij niets doen. Ze hebben geen toegangsrechten tot de server, behalve dat ze er informatie van kunnen ontvangen en dat is alles, maar in geen geval kunnen clientscripts onafhankelijk iets op de server veranderen.

De meest voorkomende servertechnologie van vandaag is PHP. Ik denk dat je, sinds je dit artikel leest, niet opnieuw hoeft stil te staan ​​bij wat het is, vooral omdat er al veel goede artikelen over dit onderwerp zijn verschenen. Laten we overtreden.

Om te beginnen hoeft u maar één ding te onthouden: vertrouw nooit de gegevens die u van de bezoeker ontvangt - het kan tenslotte een kwaadaardig script zijn, dat overigens zowel aan de serverzijde als aan de clientzijde kan staan ​​(werkt op bezoekersmachines). En dit is natuurlijk voldoende als er geen kritieke fouten in de scripts zelf voorkomen en de server zelf normaal is geconfigureerd, maar de eerste dingen eerst.

Het eerste voorbeeld dat in je opkomt is dat je hebt besloten een gastenboek te schrijven. Dit betekent dat je een veld nodig hebt om je naam, e-mailadres en het bericht zelf in te voeren. Het PHP-script ontvangt gegevens uit het formulier en slaat deze op in een speciaal bestand om later weer te geven bij het lezen van het gastenboek. Er lijkt niets gevaarlijks te zijn, maar de hacker denkt van niet; bij gebrek aan passende beveiligingsmaatregelen kan hij dit formulier voor zijn eigen doeleinden gebruiken. Nou, we geven hem geen kans.

Om te beginnen is het een goed idee om de lengte van de naam en het e-mailadres te beperken. Dit is niet alleen een van de vele methoden van gedeeltelijke bescherming, maar ook een bescherming tegen grappenmakers die denken dat een naam van enkele honderden karakters erg grappig is. Laten we dus bijvoorbeeld maxlength=25 in het invoerveld schrijven, bijvoorbeeld:

Op deze manier kan niemand meer dan 25 tekens in dit veld invoeren. Dit houdt echter alleen virtuele beginnende vandalen tegen, omdat je in de adresbalk eenvoudig zoiets kunt schrijven als:

...guest.php?user_email=ha_ha_ha_slabaja_zashita_ha_ha_ha_tyt_bil_super_haker...

Laten we een tweede klap toebrengen door zoiets als dit helemaal aan het begin van het PHP-script te schrijven:

Anders sturen we het door naar de login- en wachtwoordinvoerpagina: header ("location: index.php");

Nu we het principe van autorisatiemechanismen met behulp van sessies kennen, zullen we de knelpunten van de gepresenteerde scripts overwegen en corrigeren. De sessie-identifier, die toegang geeft tot de sessie zelf en wordt opgeslagen in de browser aan de kant van de gebruiker, wordt niet als knelpunt beschouwd.

Daar zijn veel redenen voor - te beginnen met het feit dat de identificatie korte tijd geldig is, met name als de gebruiker de site heeft verlaten, de browser heeft gesloten of lange tijd niet actief is geweest, wordt de sessie vernietigd , en eindigend met het feit dat de identificatie meestal een unieke 128-bits code is, die in de regel moeilijker is dan welk gebruikerswachtwoord dan ook.

De volgende punten zijn potentieel gevaarlijk:

Het done.php-script kan als volgt voor de gek worden gehouden: done.php?login_user=login

Om de eerste kwetsbaarheid te elimineren, is het raadzaam om alles te doen wat in het vorige artikel is beschreven, namelijk het moeilijk accepteren van een variabele alleen uit de POST-array, het controleren van $HTTP_REFERER, het controleren en bijsnijden van de variabele. Omdat we onszelf moeten beschermen tegen talloze aanvallen, kunnen we het IP-adres van de bezoeker registreren en hem bijvoorbeeld na drie mislukte pogingen gedurende 15 minuten blokkeren. Ik zou echter het gebruik van IP-blokkering afraden; dit kan gemakkelijk worden omzeild en veel gebruikers van proxyservers kunnen er last van hebben. Het is veel redelijker om een ​​autorisatievertraging toe te passen. Die. Net voordat we de juistheid van de login en het wachtwoord controleren, maken we een vertraging van bijvoorbeeld 1 seconde. Gebruikers zullen het waarschijnlijk niet eens merken, maar de brute force-snelheid van hackers zal dalen tot minder dan 1 combinatie per seconde, waardoor de mogelijkheid om een ​​wachtwoord bruut te forceren vrijwel volledig wordt geëlimineerd, zelfs met behulp van een speciaal woordenboek. Je kunt het als volgt uitstellen:

slaap(1); //vertraging gedurende 1 seconde

Wat betreft het tweede probleem met bescherming: daar is alles nog eenvoudiger. Hoewel iedereen een variabele $login_user met een willekeurige login aan het done.php-script kan doorgeven, zijn er toch enkele dingen die gedaan kunnen worden. Namelijk, om een ​​variabele te verwijderen (in PHP is het niet nodig om variabelen te declareren, dus het concept van het verwijderen van een variabele kan vergeleken worden met het wissen van een variabele) met behulp van de unset() functie; waarna we een sessie zullen openen waarin de waarde van de $login_user variabele, afkomstig van de server, wordt opgeslagen, d.w.z. de werkelijke waarde, waar de hacker op geen enkele manier invloed op heeft. Je kunt het als volgt doen:

De page.php-pagina heeft vergelijkbare inhoud, maar de link verwijst naar de index.php-pagina.

Pagina pagina.php

Wanneer u van de ene pagina naar de andere gaat, wordt onder de link het adres weergegeven van de pagina waarvandaan de overstap is gemaakt.

Element $_SERVER["HTTP_USER_AGENT"]

Het $_SERVER["HTTP_USER_AGENT"] element bevat informatie over het type en de versie van de browser en het besturingssysteem van de bezoeker.

Hier is een typische inhoud van deze regel: "Mozilla/4.0 (compatibel; MSIE 6.0; Windows NT 5.1)". De aanwezigheid van de subtekenreeks "MSIE 6.0" geeft aan dat de bezoeker de pagina bekijkt met Internet Explorer versie 6.0. De regel "Windows NT 5.1" geeft aan dat het besturingssysteem Windows XP is.

Opmerking

Voor Windows 2000 ziet het element $_SERVER["HTTP_USER_AGENT"] er als volgt uit: "Mozilla/4.0 (compatibel; MSIE 5.01; Windows NT 5.0)"), terwijl het er voor Windows XP uitziet als "Mozilla/4.0 (compatibel; MSIE 6.0 ;Windows NT 5.1)".

Als de bezoeker de Opera-browser gebruikt, kan de inhoud van $_SERVER["HTTP_USER_AGENT"] er als volgt uitzien: "Mozilla/4.0 (compatibel; MSIE 5.0; Windows 98) Opera 6.04 ".

Opmerking

De subtekenreeks "MSIE 6.0" is hier ook aanwezig, wat aangeeft dat de Opera-browser compatibel is met de Internet Explorer-browser en dezelfde dynamische Windows-bibliotheken gebruikt. Houd er daarom bij het analyseren van de door de browser geretourneerde string rekening mee dat Internet Explorer verwijst naar een string die de substring "MSIE 6.0" bevat en niet de substring "Opera". Bovendien kunnen we uit deze regel concluderen dat de gebruiker het Windows 98-besturingssysteem gebruikt.

De Firefox-browsergebruikersagent kan er als volgt uitzien: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5.

Wanneer u de Netscape-browser gebruikt, kan de inhoud van het $_SERVER["HTTP_USER_AGENT"]-element er als volgt uitzien: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1" . Het behoren tot deze browser kan worden bepaald door de aanwezigheid van de substring "Netscape". Bovendien kunt u ontdekken dat de bezoeker toegang heeft tot internet met behulp van een besturingssysteemversie van Linux, met een kernel die is geoptimaliseerd voor Pentium IV, terwijl hij zich in de grafische shell van X-Window bevindt. Dit mechanisme is handig om te gebruiken om statistische informatie te verzamelen, waardoor ontwerpers pagina's kunnen optimaliseren voor de meest voorkomende browsers.

Element $_SERVER["REMOTE_ADDR"]

Opmerking

Proxyservers zijn speciale tussenliggende servers die een speciaal soort service bieden: verkeerscompressie, gegevenscodering, aanpassing voor mobiele apparaten, enz. Onder de vele proxyservers zijn er zogenaamde anonieme proxyservers, waarmee u het echte IP-adres van de client kunt verbergen. Dergelijke servers retourneren de omgevingsvariabele HTTP_X_FORWARDED_FOR niet.

De omgevingsvariabele HTTP_X_FORWARDED_FOR wordt opgehaald

Element $_SERVER["SCRIPT_FILENAME"]

Het $_SERVER["SCRIPT_FILENAME"] element bevat het absolute pad naar het bestand vanaf de schijfroot. Dus als de server het Windows-besturingssysteem gebruikt, kan dit pad er als volgt uitzien: "d:main estindex.php", d.w.z. het pad wordt opgegeven vanaf de schijf; in een UNIX-achtig besturingssysteem wordt het pad opgegeven vanuit de hoofdmap /, bijvoorbeeld "/var/share/www/test/index.php".

Element $_SERVER["SERVER_NAME"]

Het element $_SERVER["SERVER_NAME"] bevat de naam van de server, die meestal overeenkomt met de domeinnaam van de site die zich erop bevindt.

Bijvoorbeeld,

www.softtime.ru

De inhoud van het $_SERVER["SERVER_NAME"] element is vaak hetzelfde als de inhoud van het $_SERVER["HTTP_HOST"] element. Naast de servernaam kunt u met de superglobal array $_SERVER een aantal serverparameters achterhalen, bijvoorbeeld het IP-adres van de server, de luisterpoort, welke webserver is geïnstalleerd en de versie van het HTTP-protocol. Deze informatie wordt respectievelijk in de elementen $_SERVER["SERVER_ADDR"], $_SERVER["SERVER_PORT"], $_SERVER["SERVER_SOFTWARE"] en $_SERVER["SERVER_PROTOCOL"] geplaatst.

Hieronder ziet u een voorbeeld waarbij deze elementen worden gebruikt.

Array-elementen van $_SERVER gebruiken