{"id":1766,"date":"2010-07-07T10:56:25","date_gmt":"2010-07-07T10:56:25","guid":{"rendered":"http:\/\/marcbook.local\/wds\/playground\/cybertrust\/2010\/07\/07\/writing-fuzzable-code\/"},"modified":"2023-05-15T23:13:11","modified_gmt":"2023-05-16T06:13:11","slug":"writing-fuzzable-code","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/security\/blog\/2010\/07\/07\/writing-fuzzable-code\/","title":{"rendered":"Writing Fuzzable Code"},"content":{"rendered":"
Adam Shostack here.\u00a0 One of the really exciting things about being in the Microsoft Security Engineering Center is all of the amazing collaborators we have around the company.\u00a0 People are always working to make security engineering easier and more effective.\u00a0 When we talk about security testing, we often focus on what it can\u2019t do.\u00a0 \u201cYou can\u2019t test security in,\u201d and \u201ctest will never find everything.\u201d\u00a0 But much like there\u2019s code that\u2019s easy to get wrong, there\u2019s code that\u2019s hard to test.\u00a0 Writing code to be testable has a long history, and one we don\u2019t often talk about in security.\u00a0 Today\u2019s post is from Hassan Sultan, who\u2019s responsible for one of our internal fuzzing tools.\u00a0\u00a0 We hope it inspires you to think about the question \u201cHow can I make the security of my code more easily tested?\u201d <\/span><\/p>\n And here\u2019s Hassan:<\/span><\/p>\n Security testing is an integral part of the software development lifecycle. At Microsoft, the biggest part of the security testing done is usually implemented through a technique called fuzz testing<\/i>: sending unexpected input to the product and checking whether it behaves in an acceptable way (i.e. it doesn\u2019t crash, hang, leak memory\u2026). We also use other techniques such as static source code analysis but today we\u2019re going to focus on fuzz testing and how you can best make use of it.<\/span><\/p>\n Almost every software company and every software project has to perform within constraints, they can be financial, the project has to be completed within a set budget, or time-driven, the project has to ship within a specific timeframe. The corollary is that the product must be of the highest quality possible within those constraints. How then can you perform efficient, quick and cheap security testing?<\/span><\/p>\n One approach we have started using at Microsoft is to change our engineering and test engineering practices to make fuzz testing easier, it\u2019s a little bit of additional upfront work but with great savings in terms of time and resources quickly appearing over the life of the project.<\/span><\/p>\n There are two popular approaches to fuzz testing, considering data exchanges between a producer<\/b> (the software sending data) and the consumer<\/b> (the target software processing the data):<\/span><\/p>\n A couple of things are obvious when comparing these two approaches:<\/span><\/p>\n The approach I\u2019m going to talk about is based on MITM fuzzing; the goal is to develop functionality tests in a way that makes them easily reusable as producers for MITM fuzz testing, as well as to provide a bit of functionality in the actual product to make fuzz testing more efficient. This approach makes security testing much cheaper to implement, is quite efficient and allows improving the fuzzing over time without having to rewrite numerous security tests.<\/span><\/p>\n MITM fuzzing using functionality tests has the following drawbacks:<\/span><\/p>\n The approach here is thus to fix all these problems at the source, we have listed the steps required along with each step\u2019s priority, obviously the more you do, the better, but if in a crunch, start from the top of the list and go down as far as you can.<\/span><\/p>\n (A test hook is a configuration option that modifies the product\u2019s behavior when set, it can be removed before the product ships if needed)<\/span><\/i><\/p>\n These modifications to the way tests and products are engineered are minor and cheap to implement when planned early on and will produce tremendous benefits by:<\/span><\/p>\n Ultimately, using both Generation fuzzing and MITM fuzzing would be ideal, as generation fuzzing provides a few benefits that won\u2019t be attained by MITM fuzzing(the ability to create very specific scenarios for example), but when dealing with time and resource constraints, the MITM fuzzing approach allows for efficient fuzzing that can be improved over time at a minimal cost.<\/span><\/p>\n \u00a0<\/span><\/p>\n Adam Shostack here.\u00a0 One of the really exciting things about being in the Microsoft Security Engineering Center is all of the amazing collaborators we have around the company.\u00a0 People are always working to make security engineering easier and more effective.\u00a0 When we talk about security testing, we often focus on what it can\u2019t do.\u00a0 \u201cYou […]<\/p>\n","protected":false},"author":61,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ep_exclude_from_search":false,"_classifai_error":"","footnotes":""},"content-type":[3659],"topic":[],"products":[],"threat-intelligence":[],"tags":[3825,3822],"coauthors":[1939],"class_list":["post-1766","post","type-post","status-publish","format-standard","hentry","content-type-best-practices","tag-developers","tag-microsoft-security-insights"],"yoast_head":"\n\n
\n
\n
\n
Test engineering changes for functionality tests<\/span><\/h5>\n
\n
Engineering changes in the product<\/span><\/h5>\n
\n
\n