lekken in php script
ik heb mijn script beveiligt tegen:
- sql-injections
- xxs-injections
- session hijacking
- email injections
- upload injections
- Header-bedreiging
- Include-injection
- ik heb de inlogpagina met 1 seconde vertraagt om bruto force tegen te gaan
maar zijn er nog meer lekken die je kan hebben in je php script?
Gewijzigd op 17/01/2014 17:55:03 door Christian k
volledig afhankelijk van het script/de applicatie. misschien makkelijker om daar wat meer over te zeggen?
Stoere waslijst, maar er ontbreekt nog één ding: een HTTPS-verbinding met een SSL-certificaat. Dan weten server en client dat ze direct zaken doen met elkaar — en niet met een ander of een tussenpersoon.
Als er op ingelogd wordt, of er betalingen worden gedaan, dan vind ik SSL wel uitermate belangrijk.
chats, fotos, filmpjes enzo wachtwoorden worden opgeslagen met
sha1 md5 en nog een unieke salt
Toevoeging op 17/01/2014 21:29:17:
ik heb gekeken naar CSRF maar de link
van hoe beveilig je je ertegen doet het
niet (404 page not found) dus hoe beveilig je je ertegen?
en nog een vraag hoe kan het dat bijvoorbeeld digid soms gehackt word?
ligt dat aan hun script of server en hoe beveilig je je ertegen?
hash_pbkdf2. die link van Aar werkt overigens gewoon?
SSL is een must voor een website als dit. complete error logging en activiteiten bijhouden is ook handig zodat je weet of er bijv. iemand probeert te hacken, een foutieve invoer heeft etc. CSRF idem, anders kan je worden uitgelogd door een simpel linkje of een wachtwoord worden gewijzigd door een bezoeker naar een andere website te leiden.
mocht je het echt goed aanpakken, overweeg dan een security audit door een externe partij of vraag een aantal hackers om een kijkje te nemen. jij kent je eigen code, zij niet. wellicht zien anderen of je ergens een keer bent vergeten om een query te gebruiken met prepared statements (want dat gebruik je toch, mag ik hopen?) of dat er ergens een XSS is verstopt.
mja, sha1 + md5 + salt heeft niet zo veel nut. neem eens een kijkje bij bijv. SSL is een must voor een website als dit. complete error logging en activiteiten bijhouden is ook handig zodat je weet of er bijv. iemand probeert te hacken, een foutieve invoer heeft etc. CSRF idem, anders kan je worden uitgelogd door een simpel linkje of een wachtwoord worden gewijzigd door een bezoeker naar een andere website te leiden.
mocht je het echt goed aanpakken, overweeg dan een security audit door een externe partij of vraag een aantal hackers om een kijkje te nemen. jij kent je eigen code, zij niet. wellicht zien anderen of je ergens een keer bent vergeten om een query te gebruiken met prepared statements (want dat gebruik je toch, mag ik hopen?) of dat er ergens een XSS is verstopt.
Gewijzigd op 17/01/2014 23:35:17 door Chris -
En mijn site beveiligen tegen CSRF
En waar kun je hackers inhuren?
Toevoeging op 18/01/2014 11:33:30:
En een goede ssl centificaat krijgen?
plaats een vacature hier bijvoorbeeld, komt er vanzelf iemand langs.
Hoe kan het dat snapchat digid ing enz gehackt
worden? Is dat doordat ze slecht gescript zijn met
basis fouten of ligt het aan hun servers?
phishing, servers, basis fouten, menselijke fouten.. van alles kan mogelijk zijn.
te laten om het te controleren?
en waar kun je hackers inhuren?
nogmaals, open een topic hier en zie of je berichten krijgt
voor vragen of zijn er mensen die dat als hobby doen?
voor niets gaat de zon op. je kan er op wachten tot iemand het gratis voor je doet en, indien hij/zij/ze wat vind(en) het publiceren óf je ervan op de hoogte stellen. neem je liever geen risico, zet je een bounty/beloning ervoor. no cure no pay, vinden ze iets betaal je en anders niet. denk aan bedragen tussen mid-xx voor kleine dingen, tot low xxxx voor grotere dingen.