jah, ik heb een bestandje config.php gezien, en als ik dat open kan ik dus ongeveer alles... (bestanden aanmaken, openen, wijzigen etc...)
Ik heb een cpanel host... verder kan ik daar toch weinig aan doen, of moet ik dit zelf beveiligen? (zit standaard gebruikersnaam en ww op natuurlijk)??
De kans is aannemelijker dat jij ergens een lek hebt zitten, maar dat weet je natuurlijk nooit. Je zou contact kunnen opnemen met je host, maar weet niet of die wat kunnen..
C99 is een hacking tool, dit stelt andere personen in staat om pinshing sites te instaleren op je hosting. Verwijder alle verdachte bestanden meteen, ook folders als die er al zijn.
Doorzoek je site toch maar eens grondig op lekken.. Een handige methode om te zien hoe ze het gedaan hebben is het opvragen van de apache logs, daar kan je zien welke requests deze hacker gedaan heeft om zijn file op je server te krijgen.
Lijkt me inderdaad een lek, c99.php is een bekende php shell...
Als je echt zeker weet dat die bestanden daar niet zijn geplaatst door een lek in je eigen php applicatie, dan zou ik eens je hosting provider contacteren. De server waarop jij shared hosting hebt is dan waarschijnlijk niet zo veilig(meer).
als ik in http acces logs kijk zie ik duizende regels (allemaal gets en post van bezoekers), maar als ik zoek naar config.php (bestand wat door de hacker is aangemaakt vind hij niets?)
zag nog een bestand shell.php (weet niet of dit vandaag is aangemaakt omdat ik het te snel verwijderde... toen ik dit opende zag ik ongeveer hetzelfde als net)
Dit is volgens mij niet de reden van je hack avontuurtje, hiermee kan je hoogstens wat javascript uitvoeren/cookies stelen. Je hebt ergens een remote code execution exploit staan...
Het ligt hoogst waarschijnlijk wel aan jouw code. Remote code execution komt het vaakst voor wanneer je je user input NIET of niet streng genoeg valideert. http://cwe.mitre.org/top25/#CWE-20
Ook een variabele in de URL in dit geval titel, kan je beschouwen als user input.
De HTML Purifier class is dus zeker een aanrader.
Maar zolang je niet in je Apache Logs kijkt, kan je natuurlijk niet met zekerheid uitsluiten dat het aan andere gebruikers van je shared hosting server of misschien wel aan je hosting zelf(!) ligt. Een dedicated server nemen is helemaal geen oplossing, niet als het aan jouw code ligt. Dezelfde brakke code draaien, maar dan op een eigen server neemt het gevaar niet weg.
Het is afhankelijk van wat je met die GET variabelen doet of ze een gevaar vormen of niet. Maar aangezien je die variabelen altijd op eoa manier in je code gebruikt, pas je dus best altijd veiligheidscontroles toe op deze vars.
ok, weet iemand een tutorial 0fzoiets waar ik kan vinden hoe ik dat het beste kan beveiligen? weet namelijk niet waar ik op moet zoeken
[..quote..]
Ik heb dit uit het logo gehaald.. (dat met de get), en als ik de site opnieuw open (van koen), dan krijg ik alleen de site te zien...
is deze fout nu opgelost? (ik weet namelijk niet wat ik zou moeten gezien hebben)
Persoonlijk vind ik dit precies hetzelfde als een foutmelding gaan onderdrukken met @.
Je weet niet hoe je een fout oplost dus zorg je er maar voor dat het niet meer gebruikt kan worden dmv het weghalen. Als je niet beschikt over voldoende kennis waag je dan niet aan grotere websites.
Ben jij de trotse eigenaar die ik doorlink naar mijn tutorial op de aankomende website van mij. Als je hem gelezen hebt wil je dan feedback sturen mbt leesbaarheid en inhoud? Veilig Includen / Get gebruiken
Ik vind dat een beetje onzin over het niet wagen aan grotere sites... als je altijd klein blijft zul je deze fout nooit ontdekken... een simpele hobby homepage zal bijna nooit gehackt worden... zullen ze zelfs nooit proberen. Als je eenmaal begint aan een site weet je zelfs niet hoe groot hij wordt. Verder kom je pas dingen tegen naarmate je bezig bent.
Ik onderdruk de fout niet, maar zorg dat de risicoplekken eruit worden gehaald, en zal daar iets anders op bedenken.
Ik zal verder jouw tutorial lezen en hem beoordelen.
iig bedankt daarvoor!
ArieMedia schreef:
[..quote..]Persoonlijk vind ik dit precies hetzelfde als een foutmelding gaan onderdrukken met @.
Je weet niet hoe je een fout oplost dus zorg je er maar voor dat het niet meer gebruikt kan worden dmv het weghalen. Als je niet beschikt over voldoende kennis waag je dan niet aan grotere websites.
Ben jij de trotse eigenaar die ik doorlink naar mijn tutorial op de aankomende website van mij. Als je hem gelezen hebt wil je dan feedback sturen mbt leesbaarheid en inhoud? Veilig Includen / Get gebruiken
weet verder toch iemand een oplossing voor deze $_GET...
met urlencode en decode krijg ik die script includes nog aan het werken, en dat moet niet
Edit: Maar er zijn andere manieren.. zoals PHP.net: htmlentities
of de methode die ik suggereer met een array. als je het uit een database haalt kan je het ook al heel gemakkelijk controleren door een beveiligde query uit te voeren (dus PHP.net: mysql_escape_string gebruiken) en als je geen rijen terug krijgt bestaat de pagina niet.
bij uitgebreid zoeken kon je nog andere waardes invoeren... nu heb ik dit via urlencode proberen te vermijden...
kan iemand testen of dit dus helemaal niet meer werkt? (wat ik probeer blokkeert het script nu eigenlijk allemaal)
Het is veilig nu..
&zoek=<script type="text/javascript">window.alert('hoi');</script>
Word nu niet uitgevoerd maar omgezet...
Als je iets besteld dan is dit gevaarlijk omdat je met deze code
<script type="text/javascript">window.alert(document.cookie);</script>
iemand zijn cookie kan stelen en dingen gaan bestellen ed op zijn naam.
bedankt
als iemand verder nog een fout ontdekt... zou hij/zij mij deze dan willen pm'en of mailen?
Vriendelijk bedankt allemaal
ArieMedia schreef:
Als je iets besteld dan is dit gevaarlijk omdat je met deze code
<script type="text/javascript">window.alert(document.cookie);</script>
iemand zijn cookie kan stelen en dingen gaan bestellen ed op zijn naam.
Wat bedoel je nu? heb je nog een fout ontdekt, of was dat nog over ervoor?
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Actiefste leden van de maand
