[mccode v2] Item sell code revamp ~ Last of the lot

[Guest Anonymous]

Re: [mccode v2] Item sell code revamp ~ Last of the lot

 

I take on board everything you say (that i see) and try to learn from it, in this case however i do not believe there is any task at hand to be preformed.

You have performed some basic checks -- you are using sprintf and typecasting incoming data, however you are still injecting data into a table without quoting that data.

Now on *your* game, that's fine, I've no doubt you have taken all necessary precautions elsewhere, but what about other games?

I've seen complex names for items and *very* complex names for users -- to the extent of permitting all sorts of html tags, and quotation marks).

Consider rewriting the INSERT INTO itemselllogs ... query. NEVER assume that people have the same protection you have. This is paramount to releasing quality "mods" or any type of source that interacts with the browser and/or the database.

I'd also be looking closely at every point that displays textual information from the database. Are they all properly sanitized? Again, the answer is probably yes *in your case*, but others could well be opening themselves up to a serious XSS/SCRIPT/SQLi attack here.

Finally, there is the possibility of what has been refered here as "duping". But I'll leave that one for another day - it has been discussed at length by Floydian IIRC.

4 queries -- 3 possible problems -- I'd call that serious enough to warrant attention.

[radio_active]

Re: [mccode v2] Item sell code revamp ~ Last of the lot

 

I take on board everything you say (that i see) and try to learn from it, in this case however i do not believe there is any task at hand to be preformed.

You have performed some basic checks -- you are using sprintf and typecasting incoming data, however you are still injecting data into a table without quoting that data.

Now on *your* game, that's fine, I've no doubt you have taken all necessary precautions elsewhere, but what about other games?

I've seen complex names for items and *very* complex names for users -- to the extent of permitting all sorts of html tags, and quotation marks).

Consider rewriting the INSERT INTO itemselllogs ... query. NEVER assume that people have the same protection you have. This is paramount to releasing quality "mods" or any type of source that interacts with the browser and/or the database.

I'd also be looking closely at every point that displays textual information from the database. Are they all properly sanitized? Again, the answer is probably yes *in your case*, but others could well be opening themselves up to a serious XSS/SCRIPT/SQLi attack here.

Finally, there is the possibility of what has been refered here as "duping". But I'll leave that one for another day - it has been discussed at length by Floydian IIRC.

4 queries -- 3 possible problems -- I'd call that serious enough to warrant attention.

That there is the answer i LOVE to hear, it gives me an in-depth analysis on what i should improve on and what i am doing okay. Shows me where to improve and i thank you for that. :-)

[Zero-Affect]

Re: [mccode v2] Item sell code revamp ~ Last of the lot

 

Consider rewriting the INSERT INTO itemselllogs ... query. NEVER assume that people have the same protection you have. This is paramount to releasing quality "mods" or any type of source that interacts with the browser and/or the database

that's built in with mcv2 hun...

(itemselllogs)

[radio_active]

Re: [mccode v2] Item sell code revamp ~ Last of the lot

Where it showed "ysis" in my previous post was A.nalysis but it censored out a.n.a.l!!!

 

I just revamped an original and posted it. Whether i use it or not is irrelevant. But as zero said, that log comes with the original.

[Guest Anonymous]

Re: [mccode v2] Item sell code revamp ~ Last of the lot

 

that's built in with mcv2 hun... (itemselllogs)

Indeed, *however* as it stands - the query in question WILL fail UNLESS the data is sanitized correctly. That's what I'm trying to show.

Attention to detail is everything - I've being doing it so long, I spot these things a mile off and while I won't always adhere to the rules, I know exactly when they can be broken and more to the point - why.

In this case, sure, RA's mod probably works fine and is safe on his system, but consider a system that has a less than secure front-end. Some carefully crafted queries could easily permit access to the admin console -- hence once small slip - allows for massive intrusion.

All it needs is somebody to have a poorly designed change name routine and bang -- you will be whistling for Floydian, LostOne, me or whomever to try and figure out what toerag screwed your system up.

My original post - I stand by. As I say, attention to detail is *the* order of the day - knowing exactly what ~may~ happen on environments other than yours is very tricky - and most of us can only hope to get it right -- but making that leap is critical if want to understand why systems succeed or fail (in respect of security).

Even if you only learn that you must secure EVERYTHING, not necessarily why, then that's a result. Most of the commercial work I deal with is where people are blase about security - and have missed such a thing as this either thinking "it will never happen to me" or not even knowing of it's presence. The former is IMO the worst - and that generally just pushes my prices up (call it a stupidity tax if you will).