Re: Tricky Error
- From: J Wynia <jwynia@xxxxxxxxxxxxx>
- Date: Tue, 10 May 2005 11:56:37 -0500
dracolytch wrote:
To be honest, I've already done this analysis. The SQL in the URLs are only the WHERE clauses. So, someone could go ahead and inject their own SQL to create their own custom WHERE clause. All the more power to 'em.
Most of the "classic" examples of SQL injection *are* in the WHERE clause. Many are within a specific column name portion of the WHERE clause. One of those classic examples is:
WHERE email = 'someone@xxxxxxxxxxx';
which, when injected can become
WHERE email = 'someone@xxxxxxxxxxx'; DROP TABLE members; --';
This is not the kind of system where I'm doing my "Trust no input from the user" diligence, I'm just organizing available data in an accessable format.
Given that the solution I mentioned takes less than 15 minutes, it's hard to justify *not* taking that level of diligence. To me, not passing anything important (like SQL, usernames, passwords, account information, etc.) on the URL is my default level of diligence for any project I'm putting on the web at large.
I actually use variations of the code I posted to do caching of a LOT of things. In most instances, I also wrap a date check in there or a file count that cleans up "all files created before $timestamp" or "everything but the latest 100". If the cache is going to be big, I make this a seperate script and schedule it to be called daily, etc. It's such a simple solution, I don't see how it's "over-solving" the problem.
True, your form of caching would solve the given problem, but I think it may be over-solving the problem. It could also incur additional maintenance issues once the cache reaches a couple thousand entries.
~D
I actually also frequently do this sort of caching on result sets, RSS and other remote XML, etc. as well. Many of my caches run well into the 10,000-50,000 file range and still perform quite well. In most cases, it also sped up the application in the process as getting the contents of a specific file is quicker than connecting to a database or making a remote connection to fetch content. In most of my implementations, using something similar to what I posted, I actually wrap the database fetch itself in a cache check. It's still based on an md5() of the query, but instead of storing the query, I store a serialized version of the returned array from the database. I add a quick additional check next to the file_exists to also check that it's new enough and delete as appropriate.
As long as you either add cleanup code or know the churn rate of the data is so low as to not be an issue, there is no maintenance. I see literally hundreds of apps on Sourceforge, Hotscripts, etc. that are making dozens of calls to databases on every page load for data that changes twice a year. That's a complete waste of database time.
.
- Follow-Ups:
- Re: Tricky Error
- From: dracolytch
- Re: Tricky Error
- References:
- Tricky Error
- From: dracolytch
- Re: Tricky Error
- From: J Wynia
- Re: Tricky Error
- From: dracolytch
- Tricky Error
- Prev by Date: imap_open and norsh flag
- Next by Date: Re: how does PHP5 process POST data in creating $_POST array?
- Previous by thread: Re: Tricky Error
- Next by thread: Re: Tricky Error
- Index(es):
Relevant Pages
|
