LangSec Revisited: Input Security Flaws of the Second Kind

Abstract

We consider a simple classification of input flaws in two categories: (1) flaws in processing input, with buffer overflows in parsers as the classic example and (2) flaws in forwarding input to some other system, aka injection flaws, with SQL injection and XSS as classic examples. The LangSec paradigm identifies common root causes for both categories of flaws, but much of the LangSec literature and efforts focus on the first category of flaws, esp. on techniques to eliminate parser bugs. Therefore we take a look at some existing approaches to tackling the second category of flaws, to identify (anti)patterns and place these in the LangSec perspective.

Secure Internal Data Markets

“…This might not be the case for an internal market that is seen as an add-on with limited importance to the divisions that share the data-especially in cases where there is no monetary reward for the division sharing the data. Thus, the providers of an internal data market might need to develop their own interfaces to the (proprietary) data interfaces, potentially introducing the whole set of security issues surrounding data parsing [29]. On the other hand, depending on the data market use case, the data interfaces might be far simpler than the general-purpose interfaces required in global models, thus making it possible to apply such security measures as Language Security [30].…”

Active learning for software engineering

“…These example components illustrate several benefits of our proposed approach. For example, parsers are a significant source of security vulnerabilities in programs [53,61]; and database interfaces are known sources of development and maintenance cost. Our regenerated programs can be safe-by-construction-automatically augmented with security checks-while significantly simplifying the development process.…”

“…Often this logic is scattered throughout a program, yielding what is commonly termed a "shotgun" parser, a known source of security vulnerabilities [53]. Other times, the input validation performed is insufficient to remove vulnerabilities [61].…”

Protocol automata recovery method using binary code

“…Решения данной задачи позволяет обнаруживать отклонения исследуемого протокола от эталона, выявлять отличия, возникшие в ходе реализации различных программных средств, сравнивать версионные изменения, оценивать совместимость программ, обнаруживать проблемные места. Восстановление спецификаций недокументированных протоколов и протокольных автоматов путем анализа исходных текстов программ задача весьма трудоемкая, требующая значительного времени [1][2][3], кроме того, исходные тексты не всегда доступны. Это подталкивает исследователей выбирать другие способы получения информации, позволяющей восстанавливать спецификации протоколов и протокольные автоматы, и создавать автоматизированные средства для решения проблемы.…”

“…Аналогичный обзор, представленный в источнике[5] в начале 2021 года, позволяет расширить список результатами, полученными после 2017 года, среди которых, в контексте задачи восстановления протокольных автоматов, можно выделить 2 работы[6,7]. Наиболее свежие результаты были представлены в августе 2021 года в статье[2], при этом применяется метод восстановления форматов сообщений, описанный в работе[8] тех т.пр. -текстовые протоколы, б.пр.…”