Make Your Own TRON Costume

cottonbuds writes "Apparently someone used his imagination -- with plaster, some time, a drinking straw up his nose and vaseline, combining these four elements he created a fascinating Tron costume."

Comments

11 Comments and it is gone. Wow.

[JoshMKiV]

Boy, that was quick. 2 minutes? 3 minutes?

Re:11 Comments and it is gone. Wow.

[DeTHZiT]

That's what you get for hosting a server using .NET infrastructure (or whatever the M$ marketing apes call it). I say BAH to that.

Re:Tron game...

[Rick and Roll]

Um, that's Shockwave Director, buddy.

Only supported on Windows and Macs.

How can this be redundant? I was the third comment

[rune2]

in the thread....

Re:slashdotted =)

[Tassach]

Absoloutely correct. The webuser login should not even have PERMISSION to touch the tables directly -- all access to the DB should be via stored procedures. This eliminates the possibility of a SQL injection attack. Of course there are idiot developers out there who insist on using a crappy database which doesn't have stored procedures (or which has finally just introduced limited and buggy stored procedures in it's latest version).

For people who've never worked with a real database, stored procedures work kind of like SUID programs in Unix: they run with their OWNER's permissions instead of the calling user's permissions. This allows you to let a user manipulate a table in a very controlled manner. For example, in this (contrived) Transact-SQL example:

CREATE TABLE dbo.SecurityInfo(
UserName char(32) not null,
PasswordHash char(32) not null,
CONSTRAINT PK_SecurityInfo PRIMARY KEY CLUSTERED (UserName)
)
-- populated with cookie on successful user login
CREATE TABLE dbo.SessionInfo (
UserName char(32) not null,
SessionCookie char(32) not null
CONSTRAINT PK_SesionInfo PRIMARY KEY CLUSTERED (UserName, SessionID)
go
REVOKE select, insert, update, delete ON SecurityInfo FROM WebUser
REVOKE select, insert, update, delete ON SessionInfo FROM WebUser
go

CREATE PROCEDURE SetMyPassword (
@SessionCookie char(32) = NULL
@OldPasswordHash char(32) = NULL,
@NewPasswordHash char(32) = NULL,
@Success bit OUTPUT
) AS
UPDATE SecurityInfo
SET PasswordHash = @NewPasswordHash
WHERE UserName = (SELECT UserName FROM SessionInfo WHERE SessionCookie = @SessionCookie)
AND PasswordHash = @OldPasswordHash

IF @@ROWCOUNT = 1 AND @@ERROR != 0 SELECT @Success = 1
ELSE SELECT @Success = 0
GO
GRANT execute ON SetMyPassword TO WebUser

Using this code, a web user will only be able to update his own password, assuming the client code manages the SessionCookie securely. This is as it should be.

However, if we had given the webuser SELECT and UPDATE permission on the SecurityInfo table, and had this code fragment in a PHP script:

$dbq = $db->execute("UPDATE SecurityInfo SET PasswordHash=$NewHash WHERE UserName = (SELECT UserName FROM SessionInfo WHERE SessionCookie = $SessionCookie) AND PasswordHash=$OldHash");

This leaves us open to a SQL injection attack. If the user were able to set $OLDHASH to

"'bogushash'\nGO\nSELECT * FROM SecurityInfo\nGO\nSELECT * FROM SessionInfo"

due to a bug in the PHP script (or in PHP itself), they would now have complete control over the system. Not using stored procedures as an access control layer is asking to be hacked.