views:

93

answers:

2

I'm currently reviewing the security implications of various warnings in a large Java EE application. Since most of the code is several years old, it contains many uses of the raw collection types:

List items = new List();

rather than the parametrized collection types:

List<Item> items = new List<Item>();

The only security implication I can think of is that raw types cannot be statically type-checked at compilation and could potentially result in a run-time errors such as ClassCastException which, depending on where in the code this occurs, might lead to a denial of service.

Are there any other implications of using raw types that I'm not thinking of?

+2  A: 

I can't think of any other security implications.

For non-security implications, generic types also do explicit casts* in the bytecode for types that return a generic. Of course, this is transparent to the user, and it appears that the type returned is the generic type.

For example:

List<Item> items = new ArrayList<Item>();
// .get(int) and remove(int) return Item automatically

*This happens due to type erasure.

R. Bemrose
In addition, using wrapped primitives, such as Integer and Boolean, can cause NullPointerExceptions when casting to their primitive equivalent. This happens when the variable is null. Although not explicitly a security issue, unless you are aware, and you should be as it's documented, this can cause unhandled exceptions to expose internals where you might not normally expect them.
ptomli
A: 

Lack of type safety can lead to security problems. For instance lets say this list was being used to build a query:

"select name from users where id="+items[x]

If items contained a string value of union select load_file('/var/passwd') an attacker could read an arbitrary file on your system. This is payload is assuming your using MySQL. If items was a list of integers, then this query isn't vulnerable to sql injection.

Rook
Good answer, but don't u mean "Lack of type safety can lead to security problems"
emory
@emory Thanks. yep your right, edited.
Rook
-1 Use parameterized queries. Relying on the details of the + operator when "adding" a string and an int is asking for trouble. There are loads of "dynamically typed" languages out there where nobody worries about SQL injection because the library does it right. *Stop gluing strings together and hoping that the result means what you think it means.*
tc.
@tc. its called an example. I if i used parameterized quires in my example then it wouldn't be vulnerable to sql injection. So then what the hell is the point?
Rook
So it's lack of parameterized queries (or something similar) that "leads to security problems". Explicit types will hide the problem, but I'm of the opinion that the problem is still there because it's far too easy for someone to modify it and re-add the hole (e.g. "IDs can be names or numbers").
tc.
@tc. The question is "Are there any other [security] implications of using raw types that I'm not thinking of?". I provided an example of a vulnerability that can be introduced to lack of type safety. Why are you talking about parameterized queries? How does this relate to the question? Keep in mind this question has absolutely nothing to do with sql injection and everything to do with strongly typed languages.
Rook
@tc. Would it make you feel better if I used a `FileOutputStream()` or another vulnerability on the owasp a1 -injection flaws? I used sql injection because more people understand it.
Rook
So stop gluing strings together.
tc.
@tc. for the record i always use parameterized quires because its the easiest way to prevent sql injection. However this is completely off topic. My perception of you is negative, I don't believe you are helping people. Further more i don't believe you have the ability to answer this question, mainly because you didn't post.
Rook
That's because I don't think lack of types is necessarily a "security" problem. I don't think the average Java webapp is going to be more secure than the average Python webapp. I also don't believe saying "it helps if you don't use paramaterized queries" is really an answer, and you didn't even mention paramaterized queries in your answer, suggesting that you suggest adding strings to ints as a way of preventing SQL injection..
tc.
@tc. for the record PHP made up the majority of all vulnerabilities found in 2006, things have gotten better but they still make up a large chunk. It is extremely common to see people using integer casts as input validation in weakly typed languages. Forcing type safety can make your code accidentally secure. This is a very good thing, so long as you test your code. If you are arrogant and assume you don't need to test your own code, then you have made a very vital mistake. It doesn't matter how the vulnerability is patched, testing is everything.
Rook
Because PHP makes it very easy to glue strings together. When faced between an API that's easy to get right (sqlite3_bind_int) and one that's easy to get wrong (strncat), I prefer the former; yet I see people advocate mysql_real_escape_string instead of "just use mysqli's paramteterized queries". If only anything mentioning string-escape functions started with **please use parameterized queries** it wouldn't be such a big problem; it's like **please use HTTPS** or **please use the Keychain instead of writing your own crypto**.
tc.