1) Verdiep je in de materie. Een hoop werk, maar als je 't snapt vindt zo'n pentester minder.
2) Laat de pentester z'n werk doen en zorg dat je braaf alle problemen netjes oplapt die de pentester vindt.

Het idee van een pentest is doodsimpel: Kijk of je de software dingen kunt laten doen die niet horen te kunnen gebeuren. Hoe voorkom je zulke dingen? Door je input te valideren en dus alle onterechte en ongeverifieerde aannames uit je code te verwijderen, en te vervangen door netjes gecheckte invarianten.

Dat zouden meer klanten moeten doen!

Voor jullie als leverancier zou ik zelf ASAP een ervaren pentester inhuren die bereid is ook een onderwijsrol op zich te nemen, zodat jullie programmeurs leren van tekortkomingen en jullie op tijd kunnen leveren.

Zelfstudie kan evt. ook, van oudsher is OWASP de autoriteit op het gebied van veilige web-appicaties, maar https://www.cip-overheid.nl/ bevat ook veel zinvolle richtlijnen.

Binnen het OWASP chapter in Nederland was destijds iemand die je in kunt huren, wellicht is dat een idee? En op dit forum post regelmatig iemand anoniem die zijn/haar bijdragen afsluit met "luntrus", die duidelijk veel meer van webapps weet dan ik; wie weet is luntrus ook "inhuurbaar". Succes!

Als jullie gewoon security in je software lifecycle hadden toegevoegd dan had je daar met je deadline geen problemen in moeten zien..

Verder zou ik gewoon de pentesters hun werk laten doen. Hier wordt jij als software bedrijf alleen maar beter door en het is gratis advies!

Jouw opdrachtgever zal (mits professioneel) jou alleen maar verzoeken om mogelijke issues op te lossen en zal je er niet direct op afrekenen.

Conclusie duidelijk. Je bent helemaal geen software aan het bouwen. Want anders had je wel een idee van testen gehad. Als je door een deadline gedwongen wordt om ongeteste software te leveren, dan moet je dat er zelf bij melden. We hebben effe gekeken of het zo ongeveer werkt is namelijk geen testen.

Dat zal van de gemaakte afspraken afhangen. Als de leverancier beloofd heeft op de overeengekomen opleverdatum veilige software op te leveren en deze vervolgens zo lek als een mandje blijkt te zijn, en de opdrachtgever rekent de leverancier daar niet op af, dan is die opdrachtgever niet professioneel maar een dief van z'n eigen portemonnee.

En je boft als de door de opdrachtgever ingehuurde pentesters, in hun rapportage, uitlgeggen hoe de leverancier de gevonden problemen kan oplossen, maar daar zou ik maar niet op rekenen; daar worden zij immers niet voor betaald.

Daarnaast biedt een pentest geen garantie dat alle fouten gevonden zullen worden. Sterker, als pentesters snel fouten vinden kun je er donder op zeggen dat er meer security issues zullen bestaan. Pentesters proberen aan te tonen aan dat software niet deugt, meestal in een time-box; het zijn geen probleemoplossers - in elk geval niet voor de leverancier (indien ingehuurd door de opdrachtgever).

Aangezien ik uit de woorden van de TS opmaak dat deze zich zorgen maakt, lijkt me dat geen situatie om achterover te leunen en te wachten of en waar de klant, na oplevering. over gaat klagen. Om te voorkomen dat de pentesters van de klant 1 of meer lekken/kwetsbaarheden kunnen vinden, zul je als leverancier alle lekken en kwetsbaarheden moeten vinden - en fixen.

Hoewel er vast wel cowboys zijn die amper of niet serieus testen, vermoed ik dat een ruime meerderheid van softwareleverende bedrijven wel gestructureerd functionele tests uitvoert. Helaas zijn security-tests daarbij meestal een ondergeschoven kindje - áls er al aandacht aan wordt besteed. Zie ook de tweede helft van mijn bijdrage in https://security.nl/posting/634762.

Dit is een algemene waarheid die helaas veel beginnende programmeurs niet begrijpen.
Met testen kun je niet aantonen dat een programma (anders dan een totaal triviaal programma'tje) correct werkt.
Met testen kun je alleen aantonen dat het NIET correct werkt!
Dus is het van belang dat je de correctheid van het programma op andere wijze aannemelijk maakt. Hoe precies dat
hangt er vanaf wat het precies voor programma is en welke tools en bouwstenen je gebruikt hebt, maar als het bijvoorbeeld
gaat over een website die gebruikersdata verwerkt en eventueel opslaat, een database gebruikt e.d. dan moet je
bijvoorbeeld erg uitkijken dat de werking van het programma niet afhankelijk is van de inhoud van die gebruikersdata.

Heb je bijvoorbeeld een PHP programma gemaakt en gebruik je daarin mysql_query() dan gaat dit ERG moeilijk worden!
Dat soort tools moet je dus niet gebruiken. Gelukkig werkt dat ook niet meer in PHP 7. Maar, dit is slechts een voorbeeld.

Een pentester probeert met tal van trucs de beveiliging van de applicatie te omzeilen.
Controleer dus of je alle beveiligingsmechanismen correct (waterdicht) hebt geïmplementeerd.

P.S. Als je aan projectplanning deed had je de benodigde beveiligingskennis al in een veel eerder stadium van je project ingehuurd.

Vraag je programmeur of je overal input validation en input sanitation hebt toegepast in GET/POST parameters en input forms. Dit is 50% van het werk wat de code betreft.

Zet logs van de webserver uit naar de browser, alleen output naar logfiles zodat de pentester geen feedback krijgt of zijn pogingen in de goede richting komen. Zeg je webserver tags uit, niemand hoeft te weten dat je ngix of Apache draait en met welke modules.Vraag je serverbeheerder of provider of je site of app afgeschermd draait in een sandbox.

Begin triviaal met een portscan op je webserver. Twijfel bij alles wat open staat.

Gebruik NIKTO om je URL te scannen. Daarmee behaal je al resultaat zodat de pentester serieus op zoek moet naar bugs en niet makkelijk scoort voor het ingehuurde bedrag. Deze tips kosten je geen geld.

Laat je programmeur weten dat alles aan de browser kant gemanipuleerd kan worden. In elke browser kun je een site editen en alle Javascript aanpassen, cookies en GET/POST request data aanpassen en dan op F5... dus ligt de focus op de browser of de server-side? Bij de laatste zit je goed.

Vermijd jsquery bibliotheken en als je deze gebruikt check of je een versie met weinig bugs hebt.

Login portaaltjes: zorg dat wachtwoorden raden wordt geblokkeerd na X pogingen in X tijd en sla alles wat privacygevoelig op in gehashte vormen dus geen plaintext wachtwoorden in databases. Het komt nog altijd voor.

Als je wachtwoorden laat maken op een site check de validatie (minimaal X chars, hoofdletter en een leesteken) niet via Javascript zoals veel sites dat doen maar in je backend code.

Dit is allemaal het low hanging fruit voor een pentester analyse.

Een goede pentester probeert ook ook in jouw databases te komen via de server of de provider, ook door impersonatie van jou als klant "wachtwoord vergeten" of door het hacken van andere sites op die server. Op een grote shared webhosting server heb je aanzienlijk meer risico dan een dedicated VPS die je dan wel zelf nog moet "hardenen", voorzien van firewall en IDS... Het is een uitgebreid onderwerp dus ik laat het hierbij. Bij alle software en ook webservers en PHP geldt: modules die je niet gebruikt uitzetten of verwijderen.

Wees extra voorzicht met het laten uploaden van bestanden. Een foto moet een foto zijn en geen executable of een script etc.

www.netsparker.com trial editie downloaden en draaien over je omgeving. Netsparker kent (nagenoeg) geen false positives.

Ik zou (als ik jullie was) overigens wat meer aan security expertise binnenhalen die zaken op web applicatie kan auditen.

Eminus

Ik vind pentester net zo een NULL-woord als lifecoach. Of veganpizzainfluencer.

Gezien jullie helemaal geen tijd hebben om je ergens in te verdiepen hier in drie zinnen mijn beste advies (ik ben pentester):

Vertrouw de client nooit. Ga er vanuit dat een aanvaller volledige controle heeft over zijn eigen computer en elk request dat hij/zij maar wil naar je server kan sturen, en elk bitje dat wordt opgeslagen op zijn eigen device kan zien. Valideer ALLES. ]


Nadat je dit hebt opgeleverd en je wel tijd hebt om je te verdiepen in security raad ik als beginpunt OWASP.org aan.

Security is a state of mind.

Deze uitspraak zou voor mij voldoende zijn om de opdracht terug te trekken. Doet me denken aan een project, waar ik bezwaren had tegen NTLM autorisatie/authenticatie, waarvan men riep "Security? Dat doen we in versie twee"
sic.

Security by design & by default......

Dit is zo ondertussen wel een veresite voor een opdracht. Zeker gezien de AVG wetgeving.
Elke opdrachtgever zou dit moeten eisen....

Bij web applicaties is het belangrijkste dat je voldoende beschermt tegen SQL injections of XSS (cross site scripting).
Dit zijn methodes waarbij er vanuit een kwaadwillende (of in dit geval pentester) aannames gedaan wordt over de onderliggende code en probeert deze door middel van foute input te beinvloeden (bijvoorbeeld door queries uit te voeren op de database of door cookies te stelen van gebruikers).

Zoals hiervoor al gezegd is, zorg dat je alle input, en output (als iets goed je database ingaat betekent niet dat het ook correct wordt weergegeven als het eruit komt, dit lijkt misschien overbodig, maar wordt veelal als doelwit voor XSS gebruikt) checkt!

Verder is het gewoon zorgen dat men niet zomaar op pagina's of data kan komen zonder dat zij daarvoor gemachtigd zijn (dus zorgen dat authorizatie goed op orde is).

@security

Mijn oom was een goede vriend van Age M. Age M. kreeg elke brandkast open. Want die had een thermische lans. Daar sneed hij zelds de dikste brankast mee open. Een "nette" boef ook. Nooit geweld gebruikt. Alleen na het weekend lag er wel weer een zware deur op de vloer. En alles weg.

Elke brandkast kan open. Het is maar net wat er in ligt. Want naarmate de deur dikker is, spelen twee factiren een rol. Geld en creativiteit. Het tweede wordt onderschat.

Absolute security bestaat niet. Ook niet met enceyptie of blockchain. Het zijn sprookjes. Want morgen komt Age. Met een thermische lans. Wat ik er van heb geleerd? Gewoon een extra slot overal. Want dan breken ze liever in bij de buren. Maar ook, als je dan toch de lul bent, ook een soort respect voor Age. Want slim bedacht!

Aha hier moeten wij ons dus tegen beschermen. Ik snap het nu. Sorrie voor de eerdere onzin vorig jaar en begin dit jaar.

Nessus Essentials downloaden en hiermee een Web Application Test doen.

Totdat je een keer gehacked word omdat er niet getest is.
En dan zeuren dat iets niet meer werkt.

Naast dat je een applicatie test op functionaliteit moet je dit ook testen op veiligheid.
(iets met gegevens die op "straat" liggen)

Tupperwarehousepartyconsulente is ook zo een woord.

Het is mijn vak niet, maar ik zou me marketen als veiligheidsgatenspeurneus. Liefst nog met een document dat ik voor een notaris gezworen heb dat ik nooit misbruik zal maken van wat ik doe. (Als ze je factuur niet betalen, of pas heel laat, hou dat dan nog maar eens vol!)

Als er nu ergens behoefte aan is, dan is het deskundigen die op security gebied in staat zijn om net effe verder te kijken dan de neus lang is. Maar als je mij een visitekaartje toont waar zo iets suf lulligs als "pentester" op staat dan mag je je koffie zelf afrekenen na het gesprek. Dat verkoopt toch niet? Dan denk je toch gelijk, daar zit weer zo een flapdrol met babbels? Dat is toch geen woord voor een serieus vak?

Dit gaat over jou, die pentesten zijn bedoeld om jouw systeem (systemen) te testn. Mijn zoon had een droom over pentester worden maar het bleek een ware nachtmerrie toen we samen aan de slag gingen (ik ben Java coder, lage doseringen aan code naast mijn parttime baan als docent) om geschikte werkgevers te vinden. Het is geen beroep dat "gevraagd" wordt maar er wordt wel vaker "verzocht" om pentesters / digivisiteurs. Hoe los je dat dan op vraag ik mij zelf af als ik dit nu lees denk ik misschien moet ik beter opletten... voor vacatures, je wilt toch zoals de kudde een pensioen opbouwen voor na je 67ste...

Een van mijn studenten is 15 en doet "pentesten" met Apps op de telefoon. Gewoon netwerk en exploit scans. Het wordt steeds makkelijker en alles is zo schaalbaar dat een kind de was kan doen... Ik vind dat mooi want de jeugd heeft toch de toekomst he... en nog zonder deadlines ;)