[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"detail-sidebar-cat-1-en-105":3,"doc-seo-573440-105":53,"doc-detail-573440-en":125},{"code":4,"msg":5,"data":6},0,"success",[7,14,19,24,29,34,39,44,49],{"id":8,"doc_module":9,"doc_module_name":10,"category_name":11,"show_sort_weight":12,"slug":13},11,1,"Template","Presentations",90,"presentations",{"id":15,"doc_module":9,"doc_module_name":10,"category_name":16,"show_sort_weight":17,"slug":18},12,"Resumes",80,"resumes",{"id":20,"doc_module":9,"doc_module_name":10,"category_name":21,"show_sort_weight":22,"slug":23},14,"Invoices",70,"invoices",{"id":25,"doc_module":9,"doc_module_name":10,"category_name":26,"show_sort_weight":27,"slug":28},15,"Posters",60,"posters",{"id":30,"doc_module":9,"doc_module_name":10,"category_name":31,"show_sort_weight":32,"slug":33},16,"Social Media",50,"social-media",{"id":35,"doc_module":9,"doc_module_name":10,"category_name":36,"show_sort_weight":37,"slug":38},17,"Forms",40,"forms",{"id":40,"doc_module":9,"doc_module_name":10,"category_name":41,"show_sort_weight":42,"slug":43},18,"Letters",30,"letters",{"id":45,"doc_module":9,"doc_module_name":10,"category_name":46,"show_sort_weight":47,"slug":48},21,"Paper Templates",5,"papers-templates",{"id":50,"doc_module":9,"doc_module_name":10,"category_name":51,"show_sort_weight":4,"slug":52},158,"General","general-158",{"code":4,"msg":54,"data":55},"ok",{"site_id":56,"language":57,"slug":58,"title":59,"keywords":60,"description":61,"schema_data":62,"social_meta":118,"head_meta":120,"extra_data":122,"updated_unix":124},105,"en","secure-input-handling-version-11-lecture-notes-on-software-security","Secure Input Handling - Version 1.1 - Lecture Notes on Software Security","","Secure Input Handling presents lecture notes on patterns and anti-patterns for building resilient input handling in software systems. It explains why most vulnerabilities stem from insecure or unintended parsing, and how input problems can be output problems. The notes clarify misconceptions around simply validating or sanitising inputs, contrasting validation with sanitisation and surveying terminology such as filtering and encoding. Using a parsing and LangSec perspective, it covers finding parsing bugs, injection via unintended parsing, and strategies like safe parsers, typing, and safe APIs, including tainting and safe builders.",{"@graph":63,"@context":117},[64,80,100],{"@type":65,"itemListElement":66},"BreadcrumbList",[67,71,74,77],{"item":68,"name":69,"@type":70,"position":9},"https://docshare.wps.com","Home","ListItem",{"item":72,"name":10,"@type":70,"position":73},"https://docshare.wps.com/template/",2,{"item":75,"name":11,"@type":70,"position":76},"https://docshare.wps.com/template/presentations/",3,{"item":78,"name":59,"@type":70,"position":79},"https://docshare.wps.com/template/secure-input-handling-version-11-lecture-notes-on-software-security/573440/",4,{"url":78,"name":59,"@type":81,"image":82,"author":87,"headline":59,"publisher":90,"fileFormat":93,"inLanguage":57,"description":61,"dateModified":94,"datePublished":94,"encodingFormat":93,"isAccessibleForFree":95,"interactionStatistic":96},"DigitalDocument",{"url":83,"@type":84,"width":85,"height":86},"https://docshare.wps.com/thumbnails/secure-input-handling-version-11-lecture-notes-on-software-security/573440.png","ImageObject",442,249,{"name":88,"@type":89},"Guten tag","Person",{"url":68,"name":91,"@type":92},"DocShare","Organization","application/pdf","2026-10-14",true,{"@type":97,"interactionType":98,"userInteractionCount":9},"InteractionCounter",{"@type":99},"ViewAction",{"@type":101,"mainEntity":102},"FAQPage",[103,109,113],{"name":104,"@type":105,"acceptedAnswer":106},"Why are most security vulnerabilities linked to input handling?","Question",{"text":107,"@type":108},"Most security vulnerabilities are caused by insecure input handling. These lecture notes argue that insecure, incorrect, or unintended parsing is a primary root cause, and that some input problems are actually output problems.","Answer",{"name":110,"@type":105,"acceptedAnswer":111},"Is input validation or sanitisation always the right fix?",{"text":112,"@type":108},"No. The notes explain that the common misconception is to simply validate or sanitise inputs, but that this may be a totally wrong way to tackle certain input problems. They also distinguish validation from sanitisation and show how the many related terms can create confusion.",{"name":114,"@type":105,"acceptedAnswer":115},"How do the notes propose preventing insecure parsing and injection attacks?",{"text":116,"@type":108},"They use a parsing-focused perspective inspired by the LangSec approach. The notes discuss building secure parsers, using typing and 'safe' APIs to reduce injection risks, and techniques such as tainting, tracking safe data, and safe builders.","https://schema.org",{"og:url":78,"og:type":119,"og:title":59,"og:site_name":91,"og:description":61},"article",{"robots":121,"canonical":78},"index,follow",{"doc_id":123,"site_id":56},573440,1792015519,{"code":4,"msg":5,"data":126},{"doc_id":123,"user_id":127,"nickname":88,"user_avatar":128,"doc_module":9,"category_id":8,"category_name":11,"doc_title":59,"doc_description":61,"doc_content":129,"file_id":130,"file_url":131,"file_type":132,"file_size":133,"view_count":9,"is_deleted":4,"is_public":9,"is_downloadable":9,"audit_status":9,"page_count":134,"language":135,"language_code":57,"site_id":56,"html_lang":57,"table_of_contents":136,"faqs":137,"seo_title":138,"seo_description":61,"update_tm":139,"read_time":140},687212321768,"https://ap-avatar.wpscdn.com/avatar/a0010bdbe886d2fe77?x-image-process=image/resize,m_fixed,w_180,h_180&k=1789897067658708522","Secure Input Handling  \nVersion 1 .1  \nLecture Notes on Software Security  \nErik Poll  \nDigital Security group  \nRadboud University Nijmegen  \nAugust 2024  \nSummary  \nMost security vulnerabilities are caused by insecure input handling. These lecture notes discuss the patterns and anti-patterns for secure input handling, and also for output handling, as some input problems are in fact output problems.  \nA common misconception is that we should simply validate or sanitise inputs to prevent input problems. Input validation or sanitisation may be needed, but may also be a totally wrong way to tackle some input problem. Moreover, validation and sanitisation are commonly identified (or confused) even though they are fundamentally very different notions. To make matters worse, the many (near)synonyms – filtering, encoding, escaping, neutralising and quoting – add to the confusion.  \nWe will look at input handling from the point of view of parsing. A typical application has to parse a wide variety of languages, formats and protocols. Most security problems are due to insecure, incorrect, or unintended parsing of these languages. Here these lecture notes owe a lot to the insights from the LangSec approach about the root causes of insecure input handling. Parsing provides a useful perspective to structurally prevent input handling problems: the LangSec approach for building secure parsers and the use of typing and ‘safe’APIs that are not prone to injection attacks.  \nContents  \n1 Introduction 4  \n1.1 Safe programming languages ............................. 4  \n1.2 The naive view: just add input validation and sanitisation .............. 4  \n1.3 Languages and Parsing ................................ 5  \n1.4 Exploiting Bugs vs Exploiting Features ........................ 6  \n1.5 Overview ........................................ 7  \n2 Input handling: What goes wrong, and why things go wrong. 9  \n2.1 What goes wrong: insecure parsing in the network stack .............. 9  \n2.2 What goes wrong wrong: insecure parsing at application level ........... 10  \n2.3 Finding parsing bugs: fuzzing ............................. 11  \n2.4 Incorrect parsing and parsing differentials ...................... 12  \n2.4.1 Example: NULL characters .......................... 12  \n2.4.2 Example: X.509 certificates .......................... 13  \n2.4.3 Example: email addresses .......................... 13  \n2.4.4 Example: URLs ................................ 14  \n2.4.5 Type confusion: parsing problems in programming languages ....... 15  \n2.5 Injection attacks: unintended parsing ......................... 16  \n2.5.1 Injection attacks in the execution platform itself ............... 18  \n2.6 What goes wrong: overlooking input channels .................... 21  \n2.7 What goes wrong: overlooking data flows ...................... 22  \n2.7.1 Second order attacks ............................. 22  \n2.7.2 XSS ....................................... 22  \n2.8 What goes wrong: unexpected expressivity ..................... 24  \n2.8.1 Example: UNIX file names .......................... 24  \n2.8.2 Example: Windows file names ........................ 25  \n2.9 What goes wrong: character flaws .......................... 26  \n2.10 What goes wrong: weird machines .......................... 27  \n2.11 Stateful protocols .................................... 28  \n2.12 Recap .......................................... 29  \n3 Validation, Canonicalisation and Encoding/Sanitisation 30  \n3.1 Validation ........................................ 30  \n3.2 Canonicalisation .................................... 33  \n3.3 Encoding/Sanitisation ................................. 34  \n4 How not to use input validation or input encoding 37  \n4.1 Why input validation may be the wrong approach .................. 37  \n4.2 Why input encoding may be the wrong approach .................. 37  \n4.3 Why output encoding is better ............................. 39  \n4.4 Why avoiding parsing is best ..................","cbCaictlWuxqJlVk","https://ap.wps.com/l/cbCaictlWuxqJlVk","pdf",974268,71,"English","# 1 Introduction\n## 1.1 Safe programming languages\n## 1.2 The naive view: just add input validation and sanitisation\n## 1.3 Languages and Parsing\n## 1.4 Exploiting Bugs vs Exploiting Features\n## 1.5 Overview\n# 2 Input handling: What goes wrong, and why things go wrong.\n## 2.1 What goes wrong: insecure parsing in the network stack\n## 2.2 What goes wrong wrong: insecure parsing at application level\n## 2.3 Finding parsing bugs: fuzzing\n## 2.4 Incorrect parsing and parsing differentials\n## 2.5 Injection attacks: unintended parsing\n## 2.6 What goes wrong: overlooking input channels\n## 2.7 What goes wrong: overlooking data flows\n## 2.8 What goes wrong: unexpected expressivity\n## 2.9 What goes wrong: character flaws\n## 2.10 What goes wrong: weird machines\n## 2.11 Stateful protocols\n## 2.12 Recap\n# 3 Validation, Canonicalisation and Encoding/Sanitisation\n## 3.1 Validation\n## 3.2 Canonicalisation\n## 3.3 Encoding/Sanitisation\n# 4 How not to use input validation or input encoding\n## 4.1 Why input validation may be the wrong approach\n## 4.2 Why input encoding may be the wrong approach\n## 4.3 Why output encoding is better\n## 4.4 Why avoiding parsing is best\n## 4.5 Output encodings for the web\n# 5 Langsec: preventing buggy parsing\n## 5.1 Root causes\n## 5.2 The LangSec approach\n# 6 Tackling injection attacks: preventing unintended parsing\n## 6.1 Tainting\n## 6.2 Dynamic Tainting\n## 6.3 Static tainting\n## 6.4 Tracking Safe Data: String Literals\n## 6.5 Safe builders\n## 6.6 Data flow analysis for confidentiality\n## 6.7 Recap\n# 7 Conclusions\n## 7.1 Anti-patterns and red flags\n## 7.2 Further reading","[{\"question\":\"Why are most security vulnerabilities linked to input handling?\",\"answer\":\"Most security vulnerabilities are caused by insecure input handling. These lecture notes argue that insecure, incorrect, or unintended parsing is a primary root cause, and that some input problems are actually output problems.\"},{\"question\":\"Is input validation or sanitisation always the right fix?\",\"answer\":\"No. The notes explain that the common misconception is to simply validate or sanitise inputs, but that this may be a totally wrong way to tackle certain input problems. They also distinguish validation from sanitisation and show how the many related terms can create confusion.\"},{\"question\":\"How do the notes propose preventing insecure parsing and injection attacks?\",\"answer\":\"They use a parsing-focused perspective inspired by the LangSec approach. The notes discuss building secure parsers, using typing and 'safe' APIs to reduce injection risks, and techniques such as tainting, tracking safe data, and safe builders.\"}]","Secure Input Handling - Version 1.1 - Lecture Notes on Software Security | PDF",1791939748,25]