phpBB.nl

Hoi,

Weer 'ns een vraag van mij... Ik ben bezig het phpBB sessie systeem in een site te integreren zodat ze daar maar een keer hoeven in te loggen voor de hele site. Dat gaat tot nu toe allemaal erg voorspoedig, als standaard "bovenkant" van elke file gebruik ik dit:

Code: Selecteer alles

<?php

define('IN_PHPBB', true); 
$phpbb_root_path = '../forum/'; 
include($phpbb_root_path . 'extension.inc');
include($phpbb_root_path . 'common.'.$phpEx);
include '../header.php';

// 
// Start session management 
// 
$userdata = session_pagestart($user_ip, PAGE_INDEX); 
init_userprefs($userdata); 
// 
// End session management 
//

Als ik nu op allerlei pagina's dit integreer, en het werkt goed, staat er boven deze pagina's steeds "Hacking attempt", ik weet opzich ook wel hoe dat hacking attempt werkt, maar begrijp niet waarom dit wordt laten zien nu.

In een aantal (misschien zelfs alle) bestanden in de includes map wordt gechecked of de bestanden die het bestand in de includes map include'n ook deze regel in hun bestand hebben staan:

define('IN_PHPBB', true);

Als dat er niet in staat krijg je dan die foutmelding, nu echter heb ik ook in elk bestand wat ik integreer dit regeltje geplakt. Maar het lijkt niet goed te werken, al heb ik een vermoeden waar het aan ligt, namelijk aan de directorystructuur. Omdat dit wat ingewikkeld in elkaar zit heb ik een in het bestand header.php die op elke pagina wordt geincluded de volledige url naar het phpBB forum opgenomen ipv ../forum/.

Voorbeeld:

Code: Selecteer alles

define('IN_PHPBB', true); 
$phpbb_root_path = 'http://www.site.nl/forum/'; 
include($phpbb_root_path . 'extension.inc');
include($phpbb_root_path . 'common.'.$phpEx);

Waarom ik dit gedaan heb is opzich makkelijk uit te leggen. De bestanden van de site staan in verschillende mappen, behalve de gewone hoofdmap staan er ook bestanden in mappen als "Algemeen" en "Leden" in de bestanden in deze mappen wordt de header geincluded met ../header.php opzich logisch.

Maar in de header.php worden ook bestanden geincluded voor phpBB, als ik gewoon /forum/ zal aangeven zal op een pagina als /algmeen/inloggen.php gezocht worden naar het bestand /algemeen/forum/common.php als ik de standaard header gebruik. Deze bestanden bestaan dus niet, en om een foutmelding hierover te voorkomen heb ik dus de hele url in de header.php opgenomen.

Echter geeft ie, volgens mij daardoor, deze foutmelding, ik kan natuurlijk in elk bestand die check weghalen die zoekt naar define('IN_PHPBB', true); ... maar dat lijkt me wat onnodig, ik hoop namelijk dat er een andere oplossing voor dit probleem is, ik weet alleen nog niet welke en hoe, kan iemand me hier mee helpen?

podium4 schreef:opzich logisch.

Reuze. Je verhaal is ontzettend vermoeiend.

Ik zie niet echt wat er nu misgaat, en waarom dat zo lastig is.

define('IN_PHPBB', true); plaats je alleen in de hoofdbestanden, zoals viewtopic.php, posting.php, faq.php. De bestanden die de bezoeker aanroept. In de include bestanden dus niét. Zo word voorkomen dat bezoekers direct naar bestanden als functions.php kunnen, buiten de hoofd bestanden om.

Waar gaat het in dit verhaal mis in jouw systeem?

Halverwege het typen van het verhaal ben ik even iets anders gaan doen, had ik beter niet kunnen doen

Het draait allemaal om header.php, dit bestand wordt in alle bestanden op de site ge'included. De bestanden staan behalve in de dezelfde map als header.php ook in submappen, dat levert problemen op.

Wat wil het geval?

De header.php included zelf ook een aantal bestanden van phpBB, zodat de header.php laat zien of iemand wel óf niet is ingelogd.
Het probleem nu:

site.nl/algemeen/chat.php included ../header.php, een bestand uit bovenliggende map.

header.php includes weer forum/common.php... Dit veroorzaakt dat chat.php uiteindelijk probeert algemeen/forum/common.php probeert te includen.

Dat bestand bestaat dus niet, ik heb dit opgelost door in header.php de include url te veranderen in 'http://www.site.nl/forum/common.php';

Maar nu blijkt dat common.php de foutmelding "hacking attempt" geeft als je het bestand op deze manier included. In header.php en chat.php staat wel Defined in phpbb true....

Ik begrijp dus niet waarom die melding komt, ik denk dat komt omdat ik het bestand heb geincluded met de hele url... maar weet niet of dit zo is.

Mijn vraag is dus: hoe kan ik dit oplossen zodat die foutmelding niet meer komt?

Ik heb hetzelfde systeem (met hacking attempt) op mijn eigen site. En met sommige php versies heb ik er ook problemen mee.

Je kan als beste proberen om in alle bestanden met die check achter de waarschuwing een cijfer te zetten zodat je op het scherm kan zien welke een foutmelding geeft.

Van dat bestand moet je met de chmod instellingen spelen tot dat je het niet meer hebt.

Als je het nog wel hebt (wat ik dus ook had) dan heb je een probleem. Ik heb het opgelost door de functies in .inc bestanden te zetten die niet van buitenaf gelezen kunnen worden, en dan is die check dus ook niet nodig.

//edit: (handig tegelijk typen)

De include functie werkt niet met absolute url's met de domeinnaam, nou ja, werkt wel maar dan gebruikt hij de uitvoer.

podium4 schreef:In header.php en chat.php staat wel Defined in phpbb true....

In page_header mag in_phpbb niet meer gedefineerd worden, is dat bij jou wel het geval?

podium4 schreef:Ik begrijp dus niet waarom die melding komt, ik denk dat komt omdat ik het bestand heb geincluded met de hele url... maar weet niet of dit zo is.

Dat lijkt mij niet.

WebSiteNet schreef:De include functie werkt niet met absolute url's met de domeinnaam, nou ja, werkt wel maar dan gebruikt hij de uitvoer.

Het absolute server url (intern) moet wel kunnen.

mosymuis schreef:
podium4 schreef:In header.php en chat.php staat wel Defined in phpbb true....
In page_header mag in_phpbb niet meer gedefineerd worden, is dat bij jou wel het geval?

Bij hem is het header.php en die staat in een andere map. Geeft hij er geen melding over.

mosymuis schreef:
WebSiteNet schreef:De include functie werkt niet met absolute url's met de domeinnaam, nou ja, werkt wel maar dan gebruikt hij de uitvoer.
Het absolute server url (intern) moet wel kunnen.

Er zij hier twee soorten absolute urls:

http://www.site.nl/blabla.php
/home/account/public_html/blabla.php

De laatste mag wel (als de server admin het toestaat).

Hmmm, ik zit er toch maar aan te denken om dat hele systeem van IN_PHPBB eruit te slopen, of jullie moeten nog een hele goede reden hebben om dit niet te doen. De reden waarom het gedaan is vind ik vrij nutteloos, en het oplossen van het probleem op jullie manier duurt me wat te lang...

VRIJ NUTTELOOS?!?!?!?

Lijkt me niet leuk als je code open en bloot ligt! Een beetje creatief zijn met get variabelen en je hele site ligt open!

Heb ik die IN_PHPBB nodig om mezelf te beschermen tegen mensen die allerlei dingen in de adresbalk typen? De scripts zitten volgens mij dicht genoeg om dat te voorkomen?

podium4 schreef:Hmmm, ik zit er toch maar aan te denken om dat hele systeem van IN_PHPBB eruit te slopen, of jullie moeten nog een hele goede reden hebben om dit niet te doen. De reden waarom het gedaan is vind ik vrij nutteloos, en het oplossen van het probleem op jullie manier duurt me wat te lang...

podium4 schreef:Heb ik die IN_PHPBB nodig om mezelf te beschermen tegen mensen die allerlei dingen in de adresbalk typen? De scripts zitten volgens mij dicht genoeg om dat te voorkomen?

groot gelijk volgens mij is php en de scrips genoeg beveiligt en kan die het gewoon weg halen zouw ik ook doen als ik zo veel verstand van php had

Het risico is erg laag, omdat phpBB het standaard altijd gehad heeft en er dus ook geen exploits voor bestaan. Echter, als je het weglaat zet je wel de deur open voor ervaren scripters om het een en ander op je uit te gaan testen. De mogelijkheid is er, maar deze is niet zo gevaarlijk als WSN het laat lijken.

Er zit een beperking aan wat je kan meesturen met get. Maar ik denk dat je met bestanden als includes/db.php een eind komt. Als is het alleen maar omdat je kan brute forcen als je niet weet waar phpmyadmin staat.

De database bestanden zijn juist volledig immuun omdat alles in classes staat en geen GET vars gebruikt. En wat heeft phpMyAdmin er nu weer mee te maken?

Als je db.php hebt zonder check kan je de database variabeles met get maken en zo proberen of je het wachtwoord kan krijgen. Het kan ook in phpmyadmin maar als je niet weet waar die staat kan je die ook niet brute forcen.

Maar daarvoor moet register globals op on staan en ik moet nog zoeken hoe hij kan controleren of hij verbinding heeft.

WebSiteNet schreef:Als je db.php hebt zonder check kan je de database variabeles met get maken

WebSiteNet schreef:Maar daarvoor moet register globals op on staan

Dat klopt ja, niet aan gedacht. Wat je ermee opschiet is me nog onduidelijk; je kunt errors kweken maar exploits zie ik er nog niet in. Hou zou je volgens jou daar een wachtwoord uit kunnen krijgen?

Met brute force technologie kan je proberen om achter de gebruikersnaam en wachtwoord te komen. Als die persoon cpanel hebt zal het niet moeilijk zijn om zijnsite te verwijderen omdat die voor db een overall wachtwoord heeft.

Ik zal het later een ker proberen. Lijkt me een leuk project!

phpBB.nl

Hacking attempt troubles

Hacking attempt troubles

Re: Hacking attempt troubles