| | 1 | == Fuzzing a WKWebView-based Browser session == |
| | 2 | ''by Ali Juma'' [https://drive.google.com/file/d/1mDOwqiaCv4tvBSK5PcS8-5EmkCtu2D7z/view Slide Deck] |
| | 3 | |
| | 4 | ''ajuma:'' Chrome implements WKWebView and implements features using JS injection |
| | 5 | |
| | 6 | ''ajuma:'' WKScriptMessageHandlers expose attack surface area |
| | 7 | |
| | 8 | ''ajuma:'' Fuzzing implementation uses ASan to create logs on errors |
| | 9 | |
| | 10 | ''ajuma:'' tests cases are a combination of set of fuzzed html test cases and context free |
| | 11 | |
| | 12 | ''ajuma:'' Uses google/clusterfuzz to handle overhead (dedup, etc) |
| | 13 | |
| | 14 | ''ajuma:'' iOS14+ limited js to isolated worlds, but still a good fuzzing target |
| | 15 | |
| | 16 | ''ajuma:'' Fuzzer works with a macOS script to communicate with an XCUITest test host and app host. Working directly with the iOS simulator is somewhat unreliable currently, and looking for improvements |
| | 17 | |
| | 18 | ''ajuma:'' Also looking at Catalyst builds instead of Simulator, but the Catalyst APIs seem to be an OS version behind, and no WebKit Catalyst builds. |
| | 19 | |
| | 20 | ''ajuma:'' ClusterFuzz instance is Google internal, but if there's interest we can look into sharing more widely. |
| | 21 | |
| | 22 | ''q:'' Where is the input randomization coming from? |
| | 23 | |
| | 24 | ''ajuma:'' The scripts that generate the html files are internal to Google, rand APIs come from unix apis. |
| | 25 | |
| | 26 | ''ajuma:'' Only concerned with 64bit macOS currently |
