Secure programming: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		## Foreword
2	2
3	3		This wiki page is an attempt to teach a different approach in how to create software. The page uses very simple examples to show that many problems can be taken advantage of in order to create a security attack on a computer, a program or on an entire system.
4	4
5	5		Please note that the document is only a start to teach how to write better and somewhat more secure code, but it does not attempt to be a complete guide on how to do so. In fact, it's only a brief overview of how we need to see our code and program, and how to avoid many common problems our there.
6	6
7	7		Please remember that this document is about educating for better coding, not a guide for hacking and cracking programs.
8	8
9	9		You may also be interested in [[The Power of 10]] for concise advise.
10	10
11	11		## Don't trust input
12	12
13	13		When developing a program, it is likely that it will interact with the user in some way, even if that means only reading files in the system and presenting the data.
14	14
15	15		Usually at schools and at universities when one starts to write programs, that person learns how to receive input, while teachers usually say to that person “assume that the data you receive is valid”. That's when the problems begin:
16	16
17	17		> Note: We can not trust any input that we can not control as its contents are unknown and might exploit a vulnerability in our software.
18	18
19	19		Reading from a file is reading an untrusted input, and so is reading users input, or accepting input from a network for example.
20	20
21	21		### Why can't I trust an input?
22	22
23	23		In order to understand why an input is dangerous, we first need to understand what is an input.
24	24
25	25		An input can be from a key stroke, and mouse movement or mouse button clicks, or from reading and accepting information from many other ways like a data stream or even system functions. In fact, anything your program gets from the outside is input.
26	26
27	27		It does not matter what the type of input is: for example a user or another system can give us wrong input, and the reasons can be intentional or a mistake. You can not control this input, and the main reason is that you can't guess what the input will be.
28	28
29	29		The results could be empty (NULL) “data” that the user provides us, a number that is out of our expected range, or a larger amount of chars than we expected, or even an attempt to change the address of the variable that accepts the input from the user. We just can not know what the user is going to provide.
30	30
31	31		Any “unsafe” handling of input can cause retrieval of critical information that the user is unauthorized to see, or modification of data that the user is not permitted to do, corruption of data, or even breaking (crashing) the program itself.
32	32
33	33		### What type of problems can we expect?
34	34
35	35		On every type of bug you probably will find a type of attack, but I wish to give a small list of very common types of attacks, instead of writing a lot of the attack types.
36	36
37	37		The most common attack types are:
38	38
39	39		#### Buffer Overflow
40	40
41	41		When a given data overflows the amount of memory that was allocated for it:
42	42
43	43		``` pascal
44	44		var
45	45		iNums : array [0..9] of integer;
46	46		...
47	47		FillChar (iNums[-1], 100, #0);
48	48		...
49	49		for i := -10 to 10 do
50	50		readln (iNums[i]);
51	51		...
52	52		```
53	53
54	54		In this example we can see that for the static array of iNums we gave the ability to accept only 10 numbers, while we entered to the variable a content of 21 numbers.
55	55
56	56		Please note that while the compiler might warn in simple cases, it won't in more elaborate forms.
57	57
58	58		If the user can input data that is sent to the buffer, he can supply some values that can be interpreted as machine code instructions, which will be written outside our buffer. The computer could then execute this code instead of the code that should have been there. That's a buffer overflow.
59	59
60	60		#### DoS Attack
61	61
62	62		Denial of Service is not only a network problem, but can exist also in many other ways:
63	63
64	64		``` pascal
65	65		procedure Recurse;
66	66		begin
67	67		while (True) do
68	68		begin
69	69		Recurse;
70	70		end;
71	71		end;
72	72		```
73	73
74	74		This procedure will run until the system is out of resources as it allocates more stack memory every recursion, and will cause the system to stop responding, or even crash. Although some systems – like Linux – will try to give you the ability to stop running the program, it will take a lot of time from you to do it.
75	75
76	76		Please note that this is only a static example, but we made a DoS attack on a system running this code.
77	77
78	78		Another known DoS attack is the lack of freeing system resources such as memory, sockets, file descriptors, etc...
79	79
80	80		For example:
81	81
82	82		``` pascal
83	83		...
84	84		begin
85	85		while True do
86	86		begin
87	87		Getmem(OurPtr, 10);
88	88		OurPtr := Something;
89	89		end;
90	90		end.
91	91		```
92	92
93	93		This example displays a memory allocation (Getmem is like the C malloc: it reserves memory for use), but we exit the execution without freeing the memory at the end of its use.
94	94
95	95		#### Injections
96	96
97	97		When the user gives us an input, and we are working on the given input directly without sanitizing it, the user can place in some SQL tags or code (like script code, or machine code) for example, that will cause our program to perform some action (e.g. delete some records/tables, send the user some restricted data such as database/table structure, database user and password, content of directory or file, or even execute a program at the computer).
98	98
99	99		An SQL injection example:
100	100
101	101		User Input:
102	102
103		-	~~` Please enter your name: a' OR 1=1`~~
	103	+	```text
	104	+	Please enter your name: a' OR 1=1
	105	+	```
104	106
105	107		Inside the code:
106	108
107	109		``` pascal
108	110		...
109	111		Write('Please enter your name: ');
110	112		ReadLn(sName);
111	113		Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name='#32 + sName + #32);
112	114		...
113	115		```
114	116
115	117		By submitting this SQL statement as user input, it will cause our query to add OR 1=1 to the SQL statement passed to the database: in this case, this always results in true, and the user has gained unauthorized access to the program.
116	118
117	119		## Access to your data and modification
118	120
119	121		Not only your program will have access to the data it uses. If you store the data in files or (remote) databases, an attacker can gain access through the operating system (and/or database and/or network layer/database protocol).
120	122
121	123		### Encryption: is it enough?
122	124
123	125		To counter the thread described above, programmers often use encryption. It can be used to provide:
124	126
125	127		- protection of the confidentiality of data
126	128		- non-repudiation (is the data created by the person who said he did) and integrity (is the data unchanged) (using additional mechanisms such as digital signatures/hashing)
127	129
128	130		both for
129	131
130	132		- communication of data
131	133		- storing/retrieving data
132	134
133	135		If you use these methods, your data is not automatically safe, however.
134	136
135	137		There are multiple attacks possible on encrypted data:
136	138
137	139		- attack on insecure algorithms or implementation (e.g. using a known plaintext attack)
138	140		- attack on the encryption keys (e.g. by reverse-engineering your program e.g. if it stores keys in a file or itself, or by patching the program so it intercepts encryption keys/passwords entered by the user).
139	141
140	142		If you don't know exactly what you are doing (and you won't, unless you have cryptographic training), please use (in decreasing order of preference):
141	143
142	144		- well known libraries that are maintained/patched (e.g. the built in FPC libraries, and libraries such as DCPCrypt, or external libraries like openssl or cryptlib) that use well known/widely used protocols that use well known/widely used algorithms
143	145		- Use e.g. Trusted Authentication/SSPI for SQL Server/Firebird database connectivity to avoid sending passwords over the wire (Firebird 2 and lower: in clear text!) and rely on operating system security for authentication.
144	146		- use cryptlib or openssl with Synapse to implement SSL/TLS instead of rolling your own solution
145	147		- well known/widely used protocols/APIs instead of rolling your own. These protocols must use well understood/widely used crypto/hashing algorithms. Examples:
146	148		- GPG/PGP
147	149		- TLS (SSL) with PKI/CAs (preferably don't trust only the CAs you need, and perform client certificate authentication if your threat analysis requires it)
148	150		- SSH (e.g. with public/private key authentication, if necessary reinforced with passphrases for the keys)
149	151		- on Windows, use the API to get the currently authenticated user. If you enforce proper OS security (password length, changes, physical access etc), you don't need to manage your own application leverl username/password mechanism.
150	152		- well understood crypto/hashing algorithms (such as AES/Rijndael, 3DES and SHA512). Be conservative in what algorithms you accept (e.g. MD5 is insecure for message signing).
151	153
152	154		Encryption is part of a set of possible security measures; the effort/money spent on it should be evaluated as part of a seecurity analysis (see below).
153	155
154	156		## Myths and Assumptions
155	157
156	158		Many of the security issues exist because of ignoring important warnings and information that was given by the compiler, and by thinking that your program does not contain any exploitable problem.
157	159
158	160		Here are some examples for this type of problem:
159	161
160	162		### myths
161	163
162	164		- Security by Obscurity – When no one knows about a problem no one can take advantage of it; e.g. use an obscure column name for storing passwords in your database.
163	165		- Secure programming language – There are languages such as Perl that many people think are secure from buffer overflows and other vulnerabilities while that is not true.
164	166		- Hash password is secure – A file that has a hashed password is not secure. Hash can only passed one and you can not retrieve the original data. I don't get this. Does the author mean that a hashed password can be retrieved by a brute force or rainbow table attack and that it therefore needs a salt, or multiple hash rounds? --BigChimp 16:19, 24 July 2011 (CEST)
165	167		- Nothing can break my program – Believing you're the only programmer in the world who writes faultless code is probably a bit optimistic. Maybe you're lucky and you just write code that doesn't work right without exploitable security vulnerabilies...
166	168
167	169		### assumptions
168	170
169	171		- The QA team will find and fix my security bugs.
170	172		- The user (or somebody else) will not attack my program and its data.
171	173		- My program will be used only for its original use.
172	174		- All exceptions can remain unhandled.
173	175
174	176		## Analyse to understand threats and security
175	177
176	178		In general, a programmer (or his employers/business owners) should perform an analysis of all threats (from physical access/attack through logical and social engineering attacks) should be done for the entire system (including the infrastructure – OS, database, network as well as physical machines/cabling/buildings/external connections) to analyse whether you're not leaving open a security hole that is unacceptable (from a risk/benefit perspective).
177	179
178	180		The extent of the analysis should depend on the value of the data/processes that the system protects. It obviously makes no sense to go crazy trying to analyse your house's physical security when developing a hobby program to keep track of your bridge scores.
179	181
180	182		Benefits of these kind of analyses:
181	183
182	184		- risks remaining after security measures are made known or explicit. Often, there is some discussion on the chances of this risk occurring, or the impact associated with it, but the fact that there is a remaining attack vector is at least clear and decisions can be made based on that information
183	185		- you can fairly easily see what security measures are overengineered (“too secure”, waste of money) or underengineered (“not secure enough”). If you can't use this information now, you can at least learn from it for other projects, including future maintenance/modification of your program
184	186
185	187		## Specific solutions
186	188
187	189		Now we know some problems we can encounter when developing programs, we should learn how to fix these problems. All of the problems we saw above manifest into two types: assumptions and lack of careful programming. And for learning how to fix them, we first need to learn to think in a different way than we have up to now.
188	190
189	191		### Overflow
190	192
191	193		For fixing overflow of data, like buffers and other type of input, we first of all need to identify the type of data we need to work with.
192	194
193	195		#### Buffer overflow
194	196
195	197		If we return to our example of:
196	198
197	199		``` pascal
198	200		var
199	201		iNums: array [0..9] of Integer;
200	202		...
201	203		FillChar(iNums[-1], 100, #0);
202	204		...
203	205		for i := -10 to 10 do
204	206		ReadLn(iNums[i]);
205	207		...
206	208		```
207	209
208	210		We see here a range that was overflowed by our values, without even checking if the index number is correct.
209	211
210	212		In dynamic/open arrays in Pascal we can know the limits of the allocated memory. So all we need to do is check if the size is too small or too big for our buffer, and limit the accepting for the size we wish it to be.
211	213
212	214		So the example should be changed into:
213	215
214	216		``` pascal
215	217		var
216	218		iNums: array [0..9] of Integer;
217	219
218	220		...
219	221		FillChar (iNums[Low(iNums)], High(iNums), #0);
220	222		...
221	223
222	224		for i := Low(iNums) to High(iNums) do
223	225		ReadLn(iNums[i]);
224	226		...
225	227		```
226	228
227	229		But wait, something is not right yet!
228	230
229	231		The readln will accept an unlimited amount of chars, and no one promises us that it will be an integer or even in the range we can handle.
230	232
231	233		#### Number Overflow
232	234
233	235		While a string in Pascal is a pure array (hrmm hrmm.. not really, at least not in FPC, but let's pretend it is for a second, OK ?) so readln will try to find and see what are its limits and will not try to overflow the range we gave that type, but numbers are not the same.
234	236
235	237		Numbers have limits, a computer/compiler has limits of many kinds regarding memory and numbers. It can give only a “small” amount of memory for numbers (floating point and integer numbers). And many times we do not need a large range of numbers to use (like boolean variable that needs only two numbers usually).
236	238
237	239		In the above example we may have a buffer overflow that will cause a range check error that will give us the wrong number (Carry Flag reminder issues... I'm not going to explain them in here), and we also have a DoS effect, because our program will halt from that point.
238	240
239	241		So what can we do to fix that?
240	242
241	243		First of all we may wish to work with a string variable that will be the length of the largest number +1 (for minus sign), or we can create our own readln procedure/function that will specialize with the integer type.
242	244
243	245		For the first option we can do the following (copied from the FPC documentation):
244	246
245	247		``` pascal
246	248		Program Example74;
247	249
248	250		{ Program to demonstrate the Val function. }
249	251		Var
250	252		I, Code: Integer;
251	253		begin
252	254		Val(ParamStr(1), I, Code);
253	255		If Code <> 0 then
254	256		Writeln('Error at position ', code, ' : ', Paramstr(1)[Code])
255	257		else
256	258		Writeln('Value : ', I);
257	259		end.
258	260		```
259	261
260	262		Here we see how to convert a string into an integer with some very easy error handling. The function StrToInt may also do the trick but it then we need to capture an exception in any error dealing.
261	263
262	264		Here is a small example for a small readln like procedure for integer numbers.
263	265
264	266		``` pascal
265	267		program MyReadln;
266	268		uses
267	269		CRT;
268	270
269	271		procedure MyIntReadLn(var Param: Integer; ParamLength: Integer);
270	272		var
271	273		Line: string;
272	274		ch: char;
273	275		Error: Integer;
274	276		begin
275	277		Line := '';
276	278
277	279		repeat
278	280		ch := ReadKey;
279	281		if (Length (Line) <> ParamLength) then
280	282		begin
281	283		if (ch in ['0'..'9']) then
282	284		begin
283	285		Line := Line + ch;
284	286		write (ch);
285	287		end
286	288		else
287	289		if (ch = '-') and (Length(Line) = 0) then
288	290		begin
289	291		Line := '-';
290	292		write (ch);
291	293		end;
292	294		end;
293	295
294	296		if (ch = #8) and (Length(Line) <> 0) then // backspace
295	297		begin
296	298		Line := Copy(Line, 1, Length(Line) - 1);
297	299		gotoxy(WhereX - 1, WhereY);
298	300		write(' ');
299	301		gotoxy(WhereX - 1, WhereY);
300	302		end;
301	303		until (ch = #13);
302	304
303	305		val(Line, Param, Error);
304	306
305	307		if (Error <> 0) then
306	308		Param := 0;
307	309
308	310		writeln;
309	311		end;
310	312
311	313		var
312	314		Num : Integer;
313	315		begin
314	316		Write('Number: ');
315	317		MyIntReadLn(Num, 2);
316	318		WriteLn('The number is: ', Num);
317	319		end.
318	320		```
319	321
320	322		Please note that you can make it even better, and more efficient if you wish. This is only a very small example to show how to do it.
321	323
322	324		#### What are the security risks in Overflows ?
323	325
324	326		Overflow of memory can allow arbitrary CPU code to be executed and users may run whatever type of code they wish, and nothing can stop them.
325	327
326	328		### Denial of Service
327	329
328	330		Denial of Service (DoS) is one of the hardest types of attacks to prevent. The reasons are:
329	331
330	332		- The denial of service can even be executed without any exploitable bug, like using the “ping” program on a lot of machines to DoS a machine connected to the internet.
331	333		- Every system resource can be a possible denial of service, like opening sockets, reading files or allocating memory.
332	334		- Removal of files like a kernel module can cause a big problem. I don't get this line --BigChimp 19:32, 24 July 2011 (CEST)
333	335		- Lack of configuration or wrong configuration can cause a denial of service as well if it allows vulnerable resources to be misused.
334	336		- Too much permissions or lack of them I don't get that not enough permissions can be a problem. Neither too many, either? Is a security risk, obviously but not a DoS problem. --BigChimp 19:32, 24 July 2011 (CEST) --BigChimp 19:32, 24 July 2011 (CEST).
335	337		- Almost any type of exploit can result in a denial of service.
336	338
337	339		So as you can see, a denial of service can be almost anything that can stop the system from working as it should, because of exploitation or buggy code or just a program that captures system resources..
338	340
339	341		In the above denial of service example:
340	342
341	343		``` pascal
342	344		procedure Recurse;
343	345		begin
344	346		while (True) do
345	347		begin
346	348		Recurse;
347	349		end;
348	350		end;
349	351		```
350	352
351	353		I created also a stack overflow (another type of buffer overflow), that caused the computer to need more memory resources to continue executing the code.
352	354
353	355		Any system resource that is available to the program can be abused by not returning it back to the system when the program “does not need it anymore”. The keeping of system resources like memory, or sockets remove from other programs the ability to perform some of their actions. That way most programs will stop their execution and report an error, and some will hang and keep on looking for the system resources.
354	356
355	357		Please note that some of the abuse of system resources exists because of a bug in the programming, like waiting for a 150k buffer, while the actual buffer is only 2 bytes, and when the program is still looking for the 150k buffer a new request for a 150k buffer is made etc.. until the system is not able to answer any of the requests anymore (this is a known type of attack).
356	358
357	359		A good workaround for this bug is to limit how many non full buffers can be allocated at one time. If the buffer is not full after a timeout, it should be free. However, this solution will also cause a Denial of Service, because the communication will stop anyway at some point, or a slow connection can cause data loss.
358	360
359	361		### Injection
360	362
361	363		There are many ways to inject some type of code into our programs. As we saw at the above example:
362	364
363	365		User Input:
364	366
365		-	~~` Please enter your name: a' OR 1=1`~~
	367	+	```text
	368	+	Please enter your name: a' OR 1=1
	369	+	```
366	370
367	371		Inside the code:
368	372
369	373		``` pascal
370	374		...
371	375		write('Please enter your name: ');
372	376		readln(sName);
373	377		Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name='#32 + sName + #32);
374	378		...
375	379		```
376	380
377	381		The injection occurred when we do not filter our code (sanitize is the more professional word :)): this means checking that we receive only the exact type of input that we are looking for, and nothing else.
378	382
379	383		For example, we could check if sName has spaces. If so, do not continue checking for the rest of the variable. This helps if the username is only allowed to be one word consisting of letters, maybe the tick sign (`'`) and maybe even underscore (`_`) and then it's over. If we enter a number, this should be illegal (unless we wish to use “hacker like language” (leetspeak), or allow the use of numbers.
380	384
381	385		There are many ways to sanitize your data. The less effective one (but often used) is the following:
382	386
383	387		#### Ineffective sanitising
384	388
385	389		``` pascal
386	390		function ValidVar (const S: AnsiString; AllowChars: TCharset): Boolean;
387	391		var
388	392		i: Word;
389	393		begin
390	394		i := 0;
391	395		Result := True;
392	396
393	397		while (Result) and (i <= Length(S)) do
394	398		begin
395	399		Inc(i);
396	400		Result := S[i] in AllowChars;
397	401		end;
398	402		end;
399	403		```
400	404
401	405		The function return true if we have a valid structure of content given by the AllowChars in the S variable. Please note that this function is only a proof of concept and may need more work in order to be fully used.
402	406
403	407		Another way to do the same is to use regular expression as the following (this is a Proof of concept only in the Perl language. FPC does not have a fully supported regular expression engine that allows to modify strings):
404	408
405		-	~~`$sName =~ s/[^a-z0-9_\']//gi;`~~
	409	+	```text
	410	+	$sName =~ s/[^a-z0-9_\']//gi;
	411	+	```
406	412
407	413		The regular expression removes any non valid chars from the string and returns to us the purged string. Please note that as far as I know, this regular expression will work also in ereg engines, but with minimal adjustments (g flag instructs Perl to replace all the matching patterns found. i is for case insensitivity).
408	414
409	415		Now when we know that our input is valid, we need to see what is the use of the variable content. If the variable content is going into a database, or a cgi script, or anything else that has its own syntax, we must escape the content according to the non-allowed or control characters of the relevant language (e.g. SQL for databases).
410	416
411	417		There are many ways to escape this type of content. Let's assume for now that this content is going into a query of a database. Now first of all we must make sure that our escaping will not increase our data size above the length limits of our database fields. Because if they will, then we can change from an injection to a data loss/denial of server/buffer overflow problems (a respected database usually will truncate the data and sometimes not in a good location).
412	418
413	419		Usually the only escaping we need to do for using a string in a database is to escape only the ticks (') char (although some databases may have problems with more chars then ticks). So all we should do is to represent ticks in a way that will not effect the database engine, like backslash tick (\\') or double every single tick to two ticks (''), or maybe even use another char that will be replace the ticks in the query and replace again when we will show it to the user.
414	420
415	421		#### Restricting input by SQL query parameters
416	422
417	423		Obligatory [visual illustration](https://xkcd.com/327/).
418	424
419	425		After we made sure that we respect the limits, we can continue in our attempts. To escape the code we can use several approaches. A less debugging friendly way, but a sure way of correct escaping is to use the parameters technique:
420	426
421	427		``` pascal
422	428		Query1.SQL.Add('SELECT Password FROM tblUsers WHERE Name=?');
423	429		Query1.Parameters.Add(sName);
424	430		if (Query1.Execute) then
425	431		...
426	432		```
427	433
428	434		This technique allows the database engine to escape the parameter in a way that we could use the content without any problems of illegal characters. Also, some databases have increased performance for repeated calls to this code as it can prepare an internal statement with parameters for this. The down side is that we can never debug the outcome of the query. That is, we can not see how the content of sName embedded in the SQL statement, and we can never see if our query was correct because of that.
429	435
430	436		However, once you have tested the query without parameters, adding the parameters is quite easy, so in practice, this problem is not as big as it seems.
431	437
432	438		### Efficient code
433	439
434	440		The security measures mentioned above complicate code if you used the most efficient code to get needed functionality. Fortunately, you can sometimes pass off code complications to a framework/library that deals with it. For example: in the SQL DoS example you can let the database engine deal with escaping data using parametrised queries at the small added cost of having to use parameters in your code.
435	441
436	442		However, writing performance efficient but security-vulnerable code doesn't help anybody except liability lawyers, and forensic experts.
437	443
438	444		## Beyond the document
439	445
440	446		While in this document I gave some short (yeah, I know it's an understatement 😉) examples and information on how to create better code, there are many issues that I did not touch in this document. Part of them are user privileges for execution of the programs, system root kits and other problems that our code needs to take in consideration (environment variable is only one example).
441	447
442	448		Please read more resources out there for security issues like
443	449
444	450		Buffer Overflows:
445	451
446	452		- <http://www.securiteam.com/securityreviews/5QP0L0AFFS.html>
447	453		- <http://www.securiteam.com/securityreviews/5OP0B006UQ.html>
448	454		- <http://www.securiteam.com/securityreviews/5IP0G1P8AM.html>
449	455		- <http://www.securiteam.com/securityreviews/6Q00L00BFI.html>
450	456		- <http://www.securiteam.com/securityreviews/5UP0B0A60Y.html>
451	457
452	458		Denial Of Service:
453	459
454	460		- <http://www.securiteam.com/securityreviews/5AP0V0AA1W.html>
455	461		- <http://www.securiteam.com/securityreviews/6Z00T0K95O.html>
456	462
457	463		SQL Injection:
458	464
459	465		- <http://www.securiteam.com/securityreviews/5DP0N1P76E.html>
460	466		- <http://www.securiteam.com/securityreviews/5UP010A6AA.html>
461	467		- <http://www.securiteam.com/securityreviews/5GP0E2K7FO.html>
462	468
463	469		---
464	470		From the Free Pascal wiki, page "Secure programming", as it stood on 2020-04-08 after a change by Jwdietrich, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).
465	471		Category: Code

Back to history