Member Avatar for RazorRamon

Ok over the last several weeks i've been building a website for fun. Its basically a forum site, with topics and comments. I use queries in their basic form. Now that i'm trying to protect my site I'm getting the impression that i have to rewrite all of my code.

I basically wrote the entire site with procedural code. I send most of the variables through GET through the URL because i wanted the option for the user to bookmark the site or conversation they went too.

I dont have any personal information from my users. The only thing in the Databases is tables of messages and topics. With that said i dont want a user to delete an entire database or table. I thought maybe i could just test every variable the user inputs and that is passed through the URL.

Instead of using prepared variables is it possible to just test the variables for malignant coding and prevent it from passing to the database or table?

I really dont want to rewrite the entire code. I'm at work so I dont have a lot of examples to post but heres a piece of code i emailed to myself. This is similar to the coding i'm using as far as grabbing variables from the url and passing htem to queries. I'll try to post my form comment handling code when i get home.

<?php
if(isset($_GET['id'])) 
{

include 'library/config.php';
include 'library/opendb.php'; 
$id    = $_GET['id'];
$query = "SELECT name, type, size, content " .
         "FROM upload WHERE id = '$id'";

?>
  • 5 Contributors
  • 8 Replies
  • 298 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by minitauros

Dani AI

Generated

Interpolating raw GET/POST values directly into SQL is the root cause of the holes discussed in this thread. That pattern makes injections possible and also enables stored XSS when user-supplied text is displayed without proper escaping. A full rewrite is not required — an incremental, risk-first hardening plan will secure a procedural codebase without throwing away working pages. ( and spotted the main issues and the right high-level fixes.)

Recommended incremental plan:

  • Centralize database access: add one thin DB helper that executes parameterized queries (prepared statements). Existing pages can be switched to call that helper one endpoint at a time.
  • Protect state-changing actions first: move deletes/edits to POST, enforce a server-side session ownership/role check, and require a per-form CSRF token. Do not rely on Referer headers.
  • Whitelist inputs: validate types and allowed ranges (integers, known slugs, length limits). Reject anything outside the whitelist rather than trying to filter out bad substrings.
  • Separate concerns: escape HTML at render time to prevent XSS; treat DB escaping and output escaping as different protections. ( pointed to encoding — escaping on output is the complement.)
  • Minimize blast radius: use a DB account with only the privileges needed for forum operations (avoid DROP/GRANT). Add audit logging, backups, and a staging site for changes.
  • Obfuscation is not security: base64 or similar only hides values — it does not validate or prevent injection. (’s point about obfuscation is useful for URLs, but not a substitute for parameterization.)

Example pattern to illustrate prepared execution (use a mysqli or PDO equivalent in the actual app):

$stmt = $db->prepare("SELECT * FROM posts WHERE id = ?");
$stmt->bind_param('i', $id);
$stmt->execute();

Start by fixing the highest-risk pages (delete/edit/posting) and deploy to staging. That approach keeps the procedural structure intact while dramatically reducing exposure.

Recommended Answers

All 8 Replies

Member Avatar for Member #120589

You should be able to use data from a url without any problem as long as it is sanitized, and if sensitive is checked against session data, e.g. delete a post - that should only be allowed by a mod/admin or the actual user him/herself if you want to grant that permission to users. Your code above is not secure.

Use prepared statements if possible (PDO), check input datatypes and ranges.

SEO - great use querystrings, but the only thing you really need to do is something like:

http://www.site.com?forum=17&thread=347

Or even

http://www.site.com?forum=17&thread=347#273648

or

http://www.site.com?forum=17&thread=347&post=273648

for a particular post

You could also use .htaccess files to rewrite your urls to something like http://www.site.com/17/347/273648

OK not the best example, but you get the idea.

The use of delete/edit etc may be better served with a form button (using POST method), thereby taking out the messy querystring. Just using post doesn't make the process any more secure. All $_POST variables must be considered suspect. Don't waste your time with fancy 'are they posting this form from my site or is it a spoof?' - most techniques don't work as actual headers themselves can be spoofed. The only 'simple' method I'd advise is using a random form token (hidden field) and checking it against a session value.

My 2p.

Edited by Member #120589 because: n/a
Member Avatar for veedeoo

If you did not do any filtering on the users input, they maybe able to pass DROP upload -- by way of looking at the source code of your form. My wannabie hack codes can easily drop all of your upload table, if they just know where to look for an opening.

$query = "SELECT name, type, size, content " .
         "FROM upload WHERE id = '$id' DROP upload --";

This will get executed first,

$query = "SELECT name, type, size, content " .
         "FROM upload WHERE id = '$id'

followed by this

DROP upload --

The next thing we know, the entire upload table is gone. Honestly, I really hate discussing holes and hacks in public, because it teaches people how to do it, either for fun or for some unknown personal gratifications.

Try searching online.. I have a black book I downloaded long time ago when I was 13, I experimented with it,and it work really well. However, the main concept behind the book is for protection and not to cause harm to others.

Here are the classic login tricks to hack, and you must put great efforts on how to protect your codes..

admin' --
    ' or 1=1--
    admin'/*
    ' or 1=1/*
    ' or 1=1#
    ') or ('1'='1--
     ....
     admin' #
    ') or '1'='1--
Edited by veedeoo because: DROP upload not DROP content--
Member Avatar for RazorRamon

...
SEO - great use querystrings, but the only thing you really need to do is something like:

http://www.site.com?forum=17&thread=347

Or even

http://www.site.com?forum=17&thread=347#273648

or

http://www.site.com?forum=17&thread=347&post=273648

for a particular post

You could also use .htaccess files to rewrite your urls to something like http://www.site.com/17/347/273648

OK not the best example, but you get the idea.
...

Ok so i'm guessing using words when passing through URL is a bad practice?

http://www.site.com?forum=Life&thread=kids&post=babys

To be honest this is how i'm passing most of my variables.

Edited by RazorRamon because: added to it
Member Avatar for veedeoo

no not really, you can always clean everything up, and then pass it on. Normally, people would do something like this..

somedomainDotcom/index?something=Whatever&page=somePage

Before passing the "Whatever" and "somepage" to the url, you can clean it up really well and do something like this

$something = base64_encode('Whatever');
$page = base64_encode('somepage');

and then on the processor page, you can pick it up by

$something = base64_decode($_GET['something']);
$page = base64_decode($_GET['page']);

A classic example of this is Google... take a look at their implementations..

Edited by veedeoo because: n/a
Member Avatar for Member #120589

As veedeoo states, the actual strings themselves aren't a problem, it's how you deal with them that really matters.

As far as your example goes, I can't see why you'd pass a thread string or a post string, as you now need to make the thread or post title unique in order to zero in on a specific post. IMO, you should use table id values to zero in on a thread or a post.

You can use the php filter functions to check datatype validity:

http://uk.php.net/manual/en/filter.examples.validation.php

But as I mentioned earlier, even if you are not using ORM, you can replicate this with a set of filtering functions for each input datum.

So, in other words - data will get to you in a number of different ways (cookies, get, post, external files?) and you won't be able to control some of those (get, post especially), so as opposed to worrying about what's passed, spend time on checking the data once it's arrived. :)

Member Avatar for RazorRamon

Alright thanks guys for now. I'm sure i'll have more questions as I continue to protect my site. I feel like a have a ton of learning to do when it comes to this stuff. I thought i knew PHP pretty well up until now.. lol..

Member Avatar for minitauros

Make use of the mysql_real_escape_string() function to escape certain special characters: http://nl3.php.net/manual/en/function.mysql-real-escape-string.php

Also you can convert all HTML characters to their HTML encoded equivalents. For example < would become &lt; This is done with the htmlentities() function: http://nl3.php.net/manual/en/function.htmlentities.php

You can decode this with the html_entity_decode() function: http://nl3.php.net/manual/en/function.html-entity-decode.php

Edited by minitauros because: n/a
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.