Java Applet WTF?
-
I had a user that was showing me an applet the other day and I just realized how much of a WTF it is. That I just now realized it may be TRWTF.
It was a neat little applet where you could choose what columns you wanted on your report. Then you click Select, the applet sends a request to the server, receives the results, and displays them. Pretty standard so far. However, the applet's ability to communicate with the server depends on the way the Oracle installation is configured on the machine running the applet. I don't know for sure because I haven't seen the source code, but I think the applet is making a direct connection to the Oracle server, rather than having a tier between the applet and the Oracle server. Can anyone say SQL injection?
Is there any way that this isn't a WTF?
-
There is nothing wrong with that if you're willing to let the database handle it's own security.
-
If the account the applet connects on only has read-only access to certain tables/columns, then does it make any difference?
-
writing an applet that connects to a database and for example inserts records doesn't qualify as SQL injection.
Or do I misunderstand you somehow? How would you inject SQL by selecting columns?
-
Sounds very dodgy. Presumably it's looking for Oracle's drivers? So it sounds like it's making direct database calls. Worse than that, it probably has the db connection string in the source somewhere (or at least a method of getting the connection string). Why bother with SQL Injection when I can log straight in?
-
@Pjotr G said:
writing an applet that connects to a database and for example inserts records doesn't qualify as SQL injection.
Or do I misunderstand you somehow? How would you inject SQL by selecting columns?
Java is the easiest language to decompile. If you have the .class files, you can decompile it into the .java source files. If you have the .java source files, then you can mimic that applet to do a SQL injection attack to drop tables or get data you shouldn't.
EDIT: that wouldn't really be SQL injection. You would just be creating your own SQL statement.
-
@belgariontheking said:
Java is the easiest language to decompile.
Not by a long shot - but nonetheless, it is still very easy.
-
@asuffield said:
@belgariontheking said:
Java is the easiest language to decompile.
Not by a long shot - but nonetheless, it is still very easy.
Never say any language is the most anything, or asuffield will SMACK YOU DOWN!
-
@asuffield said:
@belgariontheking said:
It's got to be up there, unless you include scripting languages that aren't compiled in the first place. C# is pretty easy, too.Java is the easiest language to decompile.
Not by a long shot - but nonetheless, it is still very easy.
-
@jcoehoorn said:
@asuffield said:
@belgariontheking said:
Java is the easiest language to decompile.
Not by a long shot - but nonetheless, it is still very easy.
It's got to be up there, unless you include scripting languages that aren't compiled in the first place. C# is pretty easy, too.
What about Assembly or
MSCIL?
-
@Pap said:
If the account the applet connects on only has read-only access to certain tables/columns, then does it make any difference?
Yes.
Select * from table1, table2, table3, . . . where 1=1;
Instant DoS attack.
-
@Critter said:
Yes.
Select * from table1, table2, table3, . . . where 1=1;
Instant DoS attack.
Are you sure? I just tried it and got an error:
C:\>Select * from table1, table2, table3, . . . where 1=1;
'Select' is not recognized as an internal or external command, operable program or batch file.
-
It's too bad no one has invented JDBC yet, that would have come in pretty handy.
-
what if the query returns all the columns, and the columns get filtered in the code after the data is retrieved?
-
@jcoehoorn said:
@asuffield said:
@belgariontheking said:
It's got to be up there, unless you include scripting languages that aren't compiled in the first place. C# is pretty easy, too.Java is the easiest language to decompile.
Not by a long shot - but nonetheless, it is still very easy.
Ignoring things like Bourne shell, the easiest lot is probably the old bytecode compilers, like elisp or perl 5. The virtual machine bytecode systems do require some effort to decompile (even if it's not that hard), while the older ones are more or less directly mapped to the source code and just need to be translated back and beautified.
-
@Random832 said:
What about Assembly
It is surprisingly tricky to write a disassembler - try it sometime, there's an annoyingly large number of special cases in all the major assembly languages. I've been playing with an x86/amd64 one for a few years, trying to find a simple specification language that can describe how to do it, and I still haven't been able to find anything that isn't Turing-complete (damned addressing modes).
-
@Pjotr G said:
what if the query returns all the columns, and the columns get filtered in the code after the data is retrieved?
What if it does?
-
@asuffield said:
@Random832 said:
I wrote a disassembler years ago for 6502 (and derivitives) That wasn't too difficult.What about Assembly
It is surprisingly tricky to write a disassembler - try it sometime, there's an annoyingly large number of special cases in all the major assembly languages. I've been playing with an x86/amd64 one for a few years, trying to find a simple specification language that can describe how to do it, and I still haven't been able to find anything that isn't Turing-complete (damned addressing modes).
-
@asuffield said:
@Random832 said:
What about Assembly
It is surprisingly tricky to write a disassembler - try it sometime, there's an annoyingly large number of special cases in all the major assembly languages.
It's particularly fun with variable-instruction-length languages like x86 assembler. I've got a program lying around somewhere that runs some code, does a jump to [program entry point + 1 byte], and does something else entirely with the same series of bytes. It's flat-out impossible to do static disassembly of this code.
-
@bw13a said:
@Pjotr G said:
what if the query returns all the columns, and the columns get filtered in the code after the data is retrieved?
What if it does?
that you can't speak of SQL injection then, but it doesn't matter cause that has already been established. The way it connects is apparently the WTF.
-
@Carnildo said:
@asuffield said:
@Random832 said:
What about Assembly
It is surprisingly tricky to write a disassembler - try it sometime, there's an annoyingly large number of special cases in all the major assembly languages.
It's particularly fun with variable-instruction-length languages like x86 assembler. I've got a program lying around somewhere that runs some code, does a jump to [program entry point + 1 byte], and does something else entirely with the same series of bytes. It's flat-out impossible to do static disassembly of this code.
It may be impossible to disassemble it to a form that is expressive of both interpretations of the series of bytes, but it’s also impossible to write code that is equally expressive of both interpretations (unless it’s just a bunch of “db” statements, expressive of neither, but, then, I can disassemble to that, too)
-
@belgariontheking said:
@Pjotr G said:
writing an applet that connects to a database and for example inserts records doesn't qualify as SQL injection.
Or do I misunderstand you somehow? How would you inject SQL by selecting columns?
Java is the easiest language to decompile. If you have the .class files, you can decompile it into the .java source files. If you have the .java source files, then you can mimic that applet to do a SQL injection attack to drop tables or get data you shouldn't.
EDIT: that wouldn't really be SQL injection. You would just be creating your own SQL statement.
Aren't the Oracle jdbc classes written in 100% java?
Just because you can connect to the port the database is listening on doesn't mean you are automatically granted access. The java class still has to authenticate the user the same way the OCI drivers would - it is the same protocol after all that the server is expecting.
-
@Quinnum said:
Aren't the Oracle jdbc classes written in 100% java?
Just because you can connect to the port the database is listening on doesn't mean you are automatically granted access. The java class still has to authenticate the user the same way the OCI drivers would - it is the same protocol after all that the server is expecting.
Oracle has JDBC drivers written 100% in java (called "thin driver"), which do not require the installation of any other Oracle client software, and they have JDBC drivers which require an Oracle client installation and are therefore not 100% written in Java.
As for the original question, if a username/password should ever be compiled into a Java applet, I would consider it wise if that username/password belongs to a user with no rights except those necessary for the applet's task.
-
You need to install the SQL extensions for DOS, clearly.
