Malicious Injection — It's Not Just For SQL Anymore 119
nywanna writes "When most people think of malicious injection, they think of SQL injection. The fact is, if you are using XML documents or an LDAP directory, you are just as vulnerable to a malicious injection as you would be using SQL. Bryan Sullivan looks at the different types of malicious code injections and examines the very basics of preventing these injections."
Old news (Score:4, Insightful)
More old news (Score:4, Insightful)
From TFA:
Seems simple enough, but it's amazing how often this is ignored or implemented badly.
know your system (Score:2, Insightful)
How come they are not well known to developers. Last time I checked if I dont use ldap somewhere along my lines
of codes I'm not in trouble of a ldap injection. Know your systems and check yours inputs! god damn!
Validate this (Score:4, Insightful)
RE: validating input fields...
I can't help but feel that most developers have at least a little common sense and do something along those lines anyway.
I often write little validate_input(char *string, char *format) that checks all input string from a user are simple, but more often than not very effective. How is this any different from using white and black lists. Any coder worth their salt would do something to stop malicious input, but no one in completely infallible.
Security of anything in this world is near on impossible. Hackers will get around anything given time.
Re:Seriously (Score:3, Insightful)
This has been true since the dawn of programming. NEVER trust the user. Oh before it was just entering text when the program expected an integer, or a negative value when it expected a positive etc. Now we don't get "? Redo from start" errors that crash the BASIC programs. But it's essentially the same thing. Never expect the user will cooperate with the program. Especially a program that is available to potentially malicious people out on the internet.
Re:If you only knew the POWER of languages (Score:1, Insightful)
That's not exactly true. There are multiple ways to break parsers by entering bogus data even into fixed length fields. For example, there were several bugs in password and user configuration utilities that took advantage of the parser not correctly handling delimiters embedded in user input. Some even took advantage of the difference in delimiters between the input screen and the backend. For example, web forms don't allow tabs as delimiters, but if the backend uses tabs then it would be problem. This won't occur if a webpage is used to input the data, but it was a trivial matter to write a script that could send the incorrect delimiters.
Comment removed (Score:5, Insightful)
Re:XML Logic Is Flawed (Score:4, Insightful)
Ignorance (Score:1, Insightful)
Re:It may sound trite, but... (Score:3, Insightful)
Re:XML Logic Is Flawed (Score:4, Insightful)
Bob
Re:Ignorance (Score:4, Insightful)
I suppose an apt analogy would be saying that it's ok to allow infectious material into a building as long as it is first correctly sealed in a bio-safe container - well that's true as long as you're sure the janitor isn't going to open it up later that evening and use it for a cookie jar.
Validation Is Not the Solution (Score:3, Insightful)
The solution I've been championing is structured composition. Instead of verifying that the input won't alter the structure of whatever you're composing, you use APIs that ensure that this won't happen. Some examples of this, as well as other bug-eliminating language/library features, can be found in my essay Better Languages for Better Software [inglorion.net].
Re:know your system (Score:3, Insightful)
Personally I have never understood why people try to hack utilities like XPath into database equivalents. But I guess if you learn how to use a hammer and screwdriver, you might well refuse to learn how to handle a wrench because you can "make" things work with the wrong tools.
Or perhaps it's a negative side-effect of object reuse fanatics who don't consider that reusability does not necessarily mean eliminating alternate implementations, but enforcing an appropriately designed and narrowed interface instead of specific implementations.
Imagine a rich reuse library that included not just default implementations, but specialized implementations that took advantage of particular tools and technologies to tweak performance, scalability, security, and reliability. ie. Instead of a generic JDBC connection with DbIO objects and methods, you could have the generic interface with specific implementations for Sybase ASE, DB/2 UDB, Oracle, PostgreSQL, SQLServer, etc. Some might not even use JDBC behind the interface. Some might rely on stored procs, others might rely on product-specific features like PostgreSQL table inheritance.
In any case, I'm reasonably certain such generic interface implementations would be much less vulnerable to injections, because even if the code were sloppy, the attacker would have to know which implementation they're attacking, not just which technology.
Personally I ALWAYS validate and quote data appropriately. A couple decades of database, systems, applications, and distributed software development teaches painful lessons through late night and weekend debugs.