Gewoon lezen. dit artikel over een Microsoft interview.

Ik had ook een interview voor een baan bij Microsoft een paar jaar geleden (in mijn geval, een PM baan in een van de server groepen).

Ik heb je ontmoet. Mark Anders in de boekenwinkel op de professionele ASP conferentie van 1999 in Islington, Londen (ik zal missen die Wrox conferenties!) en we raakten aan de praat over een aantal beveiligingsspullen - hij was vrij hoog in de ASP.NET groep op dat moment - het was volledig embryonaal toen En hij onderzocht nog steeds wat mensen van mening waren over sommige dingen... Lang verhaal kort, ik werd uitgenodigd voor Redmond.

Dus, ik vloog hierheen, kreeg een paar dagen in Seattle door te brengen, had een leuke rondleiding door Microsoft en werd uiteindelijk een dag lastig gevallen.

Een van mijn grootste problemen is dat ik erg Schots ben - je begrijpt misschien niet wat dit is betekent voor directe, vocale communicatie - maar stel je voor, Billy Connolly op twee keer de snelheid (hoewel ik een Barry Whitesque bariton:-)) - zeer dronken en met Een zak knikkers in zijn mond - dat is vrij dichtbij.

Toevoegen aan dit het feit dat ik was erg nerveus - had net ontdekt Starbucks (6 grote espresso's!) en was nog steeds jet-lagged goed, ik zou lijken te praten sommige Vreemde verloren taal.

Dus, tijdens een enkele dag ontmoette ik 8 aparte mensen in verschillende gebouwen - een enkele codering vragen (eenvoudig dingen zoals het schrijven van een zoekopdracht en het vervangen van algoritme ... de normaal), waar ik vrij goed in was. Er waren enkele 'uitvinding' en creatieve vragen

• Weer vrij goed.

Toen kwam de problemen! Ik ben wat technisch wordt genoemd absoluut bloederig verschrikkelijk in wiskunde, en vooral wiskunde puzzels wanneer onder stress - in combinatie met dat feit dat ik ben begonnen te spreken Serbo-Coratian had het niet goed voorzien.

Er waren vragen over de stroomsnelheid van auto's over een brug;op deze snelheid, hoeveel auto's passeren in 2 minuten, een over balanceerballen (die ik kreeg het antwoord op door laterale denken, niet de wiskunde benadering).

Hoe dan ook, ik werd gevraagd of ik een baan in testen zou overwegen - zei nee ... en in principe besloten Dat ik het had gehad met grote ontwikkelingsgroepen.

Dit kleurde echt mijn visie op Microsoft - het hielp me ook begrijpen een beetje van Hoe het werkt...

Ze waren op zoek naar Maths Geeks - in dit geval tenminste - Ik ben niet een, ik ben meer van de oude school hacker (in de juiste zin:-)) Ik vind het leuk om na te denken over de code Ik schrijf en vorm in een product dat mensen willen gebruiken - voor mij is het geen wiskundige oefening, veel mensen haten deze aanpak - en de meeste van de mensen die ik ontmoette bij Microsoft Ik begreep het niet.

Het ontbreken van creatief denken is een groot probleem voor de veiligheid in webbased systemen en door de jaren heen, het testen, schrijven en analyseren van deze systemen, het lijkt te zijn een van de belangrijkste oorzaken van problemen in dergelijke systemen.

Ontwikkelaars moeten creatiever nadenken over hun toepassingen, plaats jezelf in de context van een persoon die probeert om de beveiliging van uw code te breken / te ondermijnen, set limieten voor punten waar de invoer van de gebruiker is gevalideerd - de firewall van de toepassing

• Dat is je veiligheidszone.

Het is echt vrij gemakkelijk om dit te doen, als u limieten stelt op wat uw aanvraag accepteert als input.

1. Valideer de hele tijd, client en server.
2. Controleer op grenzen in het testen (wat gebeurt er als u te veel tekens invoert in een formulierveld?).
3. Vang elke fout overal waar u invoer van outwith de toepassing accepteert - zij het van de gebruiker of uit de database (ze kunnen naar beneden gaan!) .
4. Stel verstandige foutcodes in voor latere code om te controleren - veel toepassingen vallen over simpelweg omdat ze uit de sequentie vallen - met een essentiële methode die niet terugkwam de juiste waarde. Stel breekpunten in code in waar als een voorwaarde is inzet, sommige afbreken sequentie vindt plaats (het rapporteren van de fout aan de gebruiker, een redirect...etc...)
5. Vereenvoudigen - dit is het belangrijkste ding! Complexe code verbergt het zijn problemen, houden uw code leesbaar, maak uw variabele namen voor de hand liggend, voeg opmerkingen toe die de verwachte paden en gebeurtenissen naar de bron. Maak enkele klasse bestanden met dezelfde namen Hou het simpel.

Hoe dan ook, genoeg gebazel... later...