String exploits
From Wikipedia, the free encyclopedia
 |
This article or section may require cleanup to meet Wikipedia's quality standards. Please help improve this article or replace this tag with a more specific message. This article has been tagged since March 2006. (help, talk) |
String programming is believed to be easy by programmers. This is hower not the case: several implementation / design flaws are associated with string programming, some of those are associated with security exploits.
Contents |
[edit] Canonicalization problems
Software programmers often assume that strings are canonical. This a fallacy.
[edit] Example: HTML tags are not canonical
Fallacy:
"<script>" can only be written as "<script>"
This is not true. Many HTML processors will accept "<SPACEscript>" or "<NULscript>"
[edit] Concatenation problems
A lot of people believe that
String1 + User_Input_String + String2
will behave in some sort of controlled manner. This is not true.
[edit] String termination
In many environments, it is possible to truncate the string with clever input.
- PHP: %00 (NUL) can terminate strings, when used for API calls.
- Oracle: CHR(0) (NUL) can terminate strings when used for e.g. EXECUTE IMMEDIATE.
[edit] Comment out characters
In many environments, it is possible to "ask" the system to ignore the rest of the string, using "comment" characters.
- Many languages: /* means ingore everything until a */ combination.
- SQL: -- means ignore rest of line
- Unix shells: # means ignore rest of line
[edit] Related articles (other string problems)
- Format string attack - *printf format strings are dangerous
- Buffer overflow - Buffer overflows often occurs in unsafe string functions
- Cross site scripting - unsafe output of input strings
- Directory traversal - concatenating strings to create a filename is not a good idea
- SQL injection - concatenating strings to create a SQL statement is not a good idea
