Schlagwort-Archive: secure programming

Eat Less Bread?

“Eat less bread” requests a British poster from WWI. We all know it makes sense, don’t we? Resources become scarce at wartime, so wasting them weakens one’s own position. Yet this kind of advice can be utterly useless: tell a hungry person to eat less bread and you will earn, at best, a blank stare. However reasonable your advice may seem to you and everyone else, a hungry person will be physically and mentally unable to comply.

“Do not call system()” or “Do not read uninitialized memory” request secure coding guides. Such advice is equally useless if directed at a person who lacks the cognitive ability to comply. Cognitive limitations do not mean a person is stupid. We all are limited in our respective ability to process information, and we are more similar to than dissimilar from each other in this regard.

Secure coding guidelines all too often dictate a large set of arbitrary dos and don’ts, but fail to take human factors into account. Do X! Don’t do Y, do Z instead! Each of these recommendations has a sound technical basis; code becomes more secure if everyone follows this advice. However, only some of these recommendations are realistic for programmers to follow. Their sheer number should raise our doubt and let us expect that only a subset will ever be adopted by a substantial number of programmers.

Some rules are better suited for adoptions than others. Programmers often acquire idioms and conventions they perceive as helpful. Using additional parentheses for clarity, for example, even though not strictly necessary, improves readability; and the const == var convention prevents certain defects that are easy to introduce and sometimes hard to debug.

Other rules seem, from a programmer’s point of view, just ridiculous. Why is there a system() function in the first place if programmers are not supposed to use it? And if developers should not read uninitialized memory, what would warn them about memory being not initialized? Such advice is inexpensive – and likely ineffective. If we want programmers to write secure code, we must offer them platforms that make secure programming easy and straightforward and insecure programming hard and difficult.

Will HTML 5 Promote Insecure Programming? Maybe not.

[Notice for our international readers]

A few days ago the W3C published the first draft of HTML 5. One of the many new features struck me as a possible amplifier for insecure programming: HTML 5 extends the type attribute of the input element to support URLs, e-mail addresses, date, time, and other types. The rationale for the new types reads (emphasis by me):

»The idea of these new types is that the user agent can provide the user interface, such as a calendar date picker or integration with the user’s address book and submit a defined format to the server. It gives the user a better experience as his input is checked before sending it to the server meaning there is less time to wait for feedback.«

Now this is a really old theme in Web (in)security. The Web as a platform for programming invites errors in input validation and sanitation by giving the programmer equally powerful tools for two different domains of trust, the client and the server. Furthermore, client-side input validation does make sense and is desirable under usability considerations but cannot replace server-side enforcement.

Consequently, one all too common mistake in Web application programming is to validate or sanitize data on the client side but not on the server side where one must not rely on any assumptions regarding client behavior. At the first glance abovementioned extensions seem to provoke even more of these mistakes by improving on the client-side features, thus making them more attractive.

The new feature makes generating code easier, though, which means it may become easier to develop and use frameworks instead of hand-coding. This would be good, security-wise, as one framework usually makes fewer errors than hundreds or thousands of programmers.

At this time, both theories seem equally plausible to me. Empirical studies, anyone?