The Database Hacker's Handbook: Defending Database Servers

Java in SQL

We discussed Sybase Java support briefly in Chapter 13 but we should also address it here because it is one of the most security-sensitive features of Sybase. With recent versions of Sybase ASE, you can freely mix Transact-SQL and Java statements, calling Java class member functions as though they were user-defined SQL functions, declaring Java data types as though they were native to Transact-SQL, and even instantiating Java objects via parameterized constructors in a very natural way. This obviously has implications in terms of security because it significantly increases the functionality available to an attacker or a low-privileged Sybase user. There are a few things that you can't do, however, that are a little restrictive — there is no support for output parameters other than the single value returned by the Java function, and if an unhandled Java exception is raised, execution will stop at that point in a query batch. That said, these restrictions could be worked around fairly easily.

Chapter 13 briefly discussed a code snippet to portscan a remote host using Java classes from within Transact-SQL:

declare @s java.net.Socket
select @s = new java.net.Socket( "192.168.1.1", 22 )
select @s>>"close"()

This is a neat little example because it demonstrates most of what you need to understand in order to write your own Java snippets in Transact-SQL: declaration of a Java type, instantiation via a parameterized constructor, and the fact that if a Java function name is ...