10

There are a variety of ways to make sure a receiving system understands "this is data, not code" so that it doesn't try to execute or interpret the data. To name a few:

  • Prepared statements, to avoid SQL injection attacks
  • Escaping JavaScript strings, to avoid XSS attacks
  • Encoding HTML entities, to avoid HTML injection

Is there a word or phrase that covers all these cases?

(I don't think there actually is a word for this, but if there is, I figured this would be the place to ask.)

Improve this question
2
  • 1
    Good question. In this context, prepared statements are somewhat different to escaping, as they keep code and data separated without the need for escaping. I don't think there is a proper term for what you mean. Perhaps we could coin one using the Harvard architecture as a metaphor.
    – paj28
    Jan 7, 2019 at 15:59
  • 1
    Generally we think in terms of executable vs non-executable. Code is executable, data is non-executable.
    – Xander
    Jan 7, 2019 at 16:33

5 Answers 5

Reset to default
5

I believe the term you are looking for is input validation and sanitization. It is general enough to apply across multiple variations of the attack as you mentioned above and more. It would also include preventing attacks such as buffer overflows by preventing the attempted execution of code with an input that exceeds the designed limits.

EDIT - to add notes according to more specific scope

In the specific use cases presented, you are addressing the Web based attacks and are more concerned with telling the client what is data and what is code. Using this specific example, we'll dig into the HTTP protocol a bit to show what protections exists for clients and servers specific to this type of communication. The terms may vary across other protocols, but I can't possibly be expected to write about every protocol's communication in a short answer.

The best place to start with HTTP is HTML - Hyper Text Markup Language. HTML is the basis for data communication from a server to a web browser on a client. The client has a set of libraries which allow it to properly interpret the data received and take action according to the pre-programmed logic. By default, all data received is treated as data unless explicitly stated as code. In HTML that is accomplished with a script block and it's where all client side scripting takes place.

Now, this can be a concern in the event that a malicious actor finds a way to inject an ad or modify server code to serve additional blocks into the data stream that were not originally intended for the user to use. This is where injection attacks begin to take their place and need to be mitigated by both the client and the server.

On the client end, the client needs to ensure it maintains the latest updates and looks for flaws with any scriptable components within a HTTP session. Flash updates, the recent JavaScript zero day, and many other components demonstrate that the logic that supports client interpretation of server sent data is done properly. It's also important that the client prevent any type of attacks which allow the attacker to use a browser to exfiltrate data from the user's machine back to a remote server.

On the server end, the server must ensure that all requests are handled properly including the receipt of data either from GET or POST transactions. Failure to do so can allow an attacker to impact services or embed code into a previously benign web page. Data handling/input sanitization is the key here.

So the answer probably is "there isn't a set term" but it's because transactions are assumed to be data unless the markup language indicates otherwise. This is why clients can shutoff java script and still browse web pages. They receive all the same data (barring AJAX calls of course), but they don't interpret the data as code since the engine has been removed.

Improve this answer
6
  • 1
    No, those are more general terms. I'm trying to figure out if there's a word that means the particular technique of declaring "this is data, not code" so that the client doesn't execute or interpret the data. The technique itself, not the ways to implement it. I'm not sure there is a word for this, but I figured this would be the place to ask.
    – Kevin Smith
    Jan 7, 2019 at 13:50
  • 1
    @KevinSmith In memory at least, the term is NX (or DEP).
    – forest
    Jan 7, 2019 at 13:56
  • @forest Oh yes, now we're onto something!
    – Kevin Smith
    Jan 7, 2019 at 14:25
  • @KevinSmith It's specific to memory though. Prepared statements and the like would not be considered NX.
    – forest
    Jan 7, 2019 at 14:26
  • 1
    "Sanitization" is a viable answer, but "validation" is a separate task from the things described in this question. Also, I would think of "sanitization" as a process that gives back a transformed version of the input data; SQL prepared statements alleviate the need for sanitization.
    – ShapeOfMatter
    Jan 7, 2019 at 16:11
5

I don't know that there's a single word for this, but in practice I've heard this referred to as "separation of code and data".

There's more to this than simply security, however. It's also a design principle, and gets you practical things being able to more easily configure a program. If you have config values buried inside your code, for instance, changing the config values means having to edit source code, possibly re-compiling, and having more knowledgeable people perform this task.

It's perhaps important to note that that this idea goes back to the 1940s, with our current "Von Neumann Architecture" where the data is stored along with the code in memory. Previous to this the "code" was hard wired into the machine, and could not be modified without physically re-wiring the computer. The Von Neumann Architecture allows the code to be easily modified since it's just stored information in memory. As we've found out this is a bit of a double edged sword, and that same flexibility has lead to many security problems. (Leading to the solutions you're talking about, more explicitly separating the two)

It's also worth noting that being a design principle, there are people who advocate not separating code from data. Look at a language like Lisp, for instance.

Improve this answer
0
2

I don't know of a single word for the three examples you've given; I actually think you're clumping together two different things.

Encoding and character-escaping are tactics for data sanitization. A block of data is transformed into an equivalent (or suitable) representation such that parts of your system that could interpret parts of that data as code to be executed don't.

SQL prepared statements I would describe as binding the data to { names | ids | references | pointers } in a static type system. A block of data (e.g. text) is bound to a typed identifier (e.g. $1) within the context of a statically typed system (e.g. the SQL database server). This guarantees that nothing within that system will interpret the data as code to be executed (unless they explicitly call a text→code function).

Static typing is in some ways better; it offers syntactic guarantees and doesn't change the data in question. On the other hand its guarantees only apply within that one context; for example using a statically typed language for your application layer doesn't protect you from SQL injection.

Improve this answer
2

In case it helps: perl uses a concept of "tainting", where input data is "tainted" and can not be used in certain contexts (e.g. to construct a file name) until validated/sanitized.

Improve this answer
1

This could be considered executable space protection/DEP?

https://en.wikipedia.org/wiki/Executable_space_protection

Basically just marking memory regions as non-executable - typically this is less of a web app thing afaik, but the concept is very similar imo?

Here's one of my favorite presentations on it: http://security.cs.rpi.edu/courses/binexp-spring2015/lectures/11/07_lecture.pdf

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .