Content deleted Content added
m Task 18 (cosmetic): eval 3 templates: del empty params (2×); |
Removing link(s) to "Secure by default": Removing links to deleted page Secure by default. |
||
| (27 intermediate revisions by 20 users not shown) | |||
Line 1:
{{Short description|Software development methodology}}
{{Multiple issues|
{{
{{More footnotes|date=September 2010}}
}}
'''Secure coding''' is the practice of developing computer [[software]] in such a way that guards against the accidental introduction of [[security vulnerabilities]]. Defects, [[Software bug|bugs]] and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities.<ref name="bss2001">{{Cite book| last = Viega | first = John |author2=Gary McGraw | title = Building Secure Software: How to Avoid Security Problems the Right Way | year = 2001 | publisher = MAddison-Wesley Professional | pages = 528 | isbn = 978-0201721522 }}</ref> Through the analysis of thousands of reported vulnerabilities, security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors. By identifying the insecure coding practices that lead to these errors and educating developers on secure alternatives, organizations can take proactive steps to help significantly reduce or eliminate vulnerabilities in software before deployment.<ref>{{Cite
{{Computer security}}▼
Some scholars have suggested that in order to effectively confront threats related to [[Computer security|cybersecurity]], proper security should be coded or “baked in” to the systems. With security being designed into the software, this ensures that there will be protection against insider attacks and reduces the threat to application security.<ref>{{Cite journal |last=Russell L |first=Jones |date=Dec 2004 |title=Secure Coding: Building Security into the Software Development Life Cycle |url=https://www.proquest.com/docview/229507883 |journal=Information Systems Security|id={{ProQuest|229507883}} }}</ref>
▲'''Secure coding''' is the practice of developing computer [[software]] in a way that guards against the accidental introduction of security vulnerabilities. Defects, [[Software bug|bugs]] and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities.<ref name="bss2001">{{Cite book| last = Viega | first = John |author2=Gary McGraw | title = Building Secure Software: How to Avoid Security Problems the Right Way | year = 2001 | publisher = MAddison-Wesley Professional | pages = 528 | isbn = 978-0201721522 }}</ref> Through the analysis of thousands of reported vulnerabilities, security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors. By identifying the insecure coding practices that lead to these errors and educating developers on secure alternatives, organizations can take proactive steps to help significantly reduce or eliminate vulnerabilities in software before deployment.<ref>{{Cite journal|last=Taylor|first=Blair|last2=Azadegan|first2=Shiva|date=2006-09-22|title=Threading secure coding principles and risk analysis into the undergraduate computer science and information systems curriculum|url=https://doi.org/10.1145/1231047.1231053|journal=Proceedings of the 3rd annual conference on Information security curriculum development|series=InfoSecCD '06|___location=Kennesaw, Georgia|publisher=Association for Computing Machinery|pages=24–29|doi=10.1145/1231047.1231053|isbn=978-1-59593-437-6}}</ref>
== Buffer-overflow prevention ==
Line 13 ⟶ 14:
An example of a [[C (programming language)|C]] program prone to a buffer overflow is<syntaxhighlight lang="c++">
int vulnerable_function(char * large_user_input) {
}
</syntaxhighlight>If the user input is larger than the destination buffer, a buffer overflow will occur.
Line 20 ⟶ 21:
To fix this unsafe program, use strncpy to prevent a possible buffer overflow.<syntaxhighlight lang="c++">
int secure_function(char * user_input) {
// copy a maximum of BUF_SIZE bytes
// set the last character in the buffer to NUL.
dst[BUF_SIZE -1] = '\0';
}
</syntaxhighlight>Another secure alternative is to dynamically allocate memory on the heap using [[malloc]].<syntaxhighlight lang="c++">
char * secure_copy(char * src) {
}
}
</syntaxhighlight>In the above code snippet, the program attempts to copy the contents of '''''src''''' into '''''dst
== Format-string attack prevention ==
Line 44 ⟶ 47:
printf(malicious_input);
}
</syntaxhighlight>A malicious argument passed to the program could be
== Integer-overflow prevention ==
Line 56 ⟶ 59:
}
</syntaxhighlight>
The problem with the code is it does not check for integer overflow on the addition operation. If the sum of x and y is greater than the maximum possible value of an <code>unsigned int</code>, the addition operation will overflow and perhaps<!-- Note that an overflow will not always result in the calculated sum being less than MAX; MAX might be relatively small and both x and y relatively big, so even an overflow might still be greater than MAX. Example: x=y=UINT_MAX, MAX=1000000. --> result in a value less than or equal to MAX, even though the sum of x and y is greater than MAX.
Below is a function which checks for overflow by confirming the sum is greater than or equal to both x and y. If the sum did overflow, the sum would be less than x or less than y.
Line 66 ⟶ 69:
</syntaxhighlight>
== Path
Path
For example, consider a script that fetches an article by taking a filename, which is then read by the script and [[
<nowiki>
If the script has no input checking, instead trusting that the filename is always valid, a [[malicious user]] could forge a URL to retrieve configuration files from the
<nowiki>
Depending on the script, this may expose the [[Passwd#Password file|/etc/passwd]] file, which on [[Unix-like]] systems contains (among others) [[User identifier (Unix)|user IDs]], their [[Username|login names]], [[home directory]] paths and [[Operating system shell|shells]]. (See [[SQL injection]] for a similar attack.)
== See also ==
* [[Application security|Application Security]]
* [[Defensive programming]]
* [[Security bug]]
* Secure by default
==
{{Reflist}}
== References ==
* {{Cite book| last = Taylor | first = Art |author2=Brian Buege |author3=Randy Layman | title = Hacking Exposed J2EE & Java | year = 2006 | publisher = McGraw-Hill Primis | pages = 426 | isbn = 0-390-59975-1 }}
▲{{Computer security}}
{{DEFAULTSORT:Secure Coding}}
[[Category:Computer security]]
| |||