Jump to content

My first website


arbitter

Recommended Posts

2. Escaping all data that will interact with your db.  This will prevent injection attacks.  And, no, addslashes won't cut it.  You need to use the escape function that's related to the db you're using (like, say, mysql_real_escape_string).

 

i agree 100%, regex is the best way to validate input, i dont have any right now, but there are prebuilt regex functions you can use, search around for them.

Link to comment
Share on other sites

I'll find out some more about regex the I guess :) Not that it's necessary for my site, but perhaps for the future it could come in handy.

 

And another problem;

"Warning: mysql_real_escape_string() [function.mysql-real-escape-string]: Access denied for user 'apache'@'localhost' (using password: NO) in"

"Warning: mysql_real_escape_string() [function.mysql-real-escape-string]: A link to the server could not be established in"

Link to comment
Share on other sites

Oh boy, my bad.

I thought this was the problem so I connected to my database earlier, but the mysql_real_escape_string() was one line before the connection...

 

Though the problem is now; does this infect characters as a '/' ?

Link to comment
Share on other sites

Oh boy, my bad.

I thought this was the problem so I connected to my database earlier, but the mysql_real_escape_string() was one line before the connection...

 

Though the problem is now; does this infect characters as a '/' ?

 

It adds an escape character ('\') during data insertion/updating, but it shouldn't be visible during data retrieval.  If you do see an escape character during data retrieval, chances are you have magic quotes on, which is considered a no-no (if memory serves, it should be turned off by default in PHP5, and may be completely removed from the language when version 6 is finally released).

Link to comment
Share on other sites

Oh boy, my bad.

I thought this was the problem so I connected to my database earlier, but the mysql_real_escape_string() was one line before the connection...

 

Though the problem is now; does this infect characters as a '/' ?

 

It adds an escape character ('\') during data insertion/updating, but it shouldn't be visible during data retrieval.  If you do see an escape character during data retrieval, chances are you have magic quotes on, which is considered a no-no (if memory serves, it should be turned off by default in PHP5, and may be completely removed from the language when version 6 is finally released).

 

So if I type in "what/ever" it returns "what\/ever" ?

Because I'm trying to implement it in my password, but the point is that my passwords get md5()'ed. And they get md5()'ed before they enter the mysql database.

 

So should I:

1) md5() the "\" with the password, so nevertheless my passwords containing slashes work

2) leave it like this, because md5() always returns Letters and numbers...

Link to comment
Share on other sites

what\ever should return what\\ever  the "\" nullifys the effect of the following character. so by adding the slash it nullifies someones attempt to nullify your quote. and injection would like this

here is your sql

SELECT * FROM users WHERE username = "user1" AND password = "password"

 

the user enteres >badpassword" or 1=1\<

 

here is the string rendered so you see whats inside the varibale you put in the string

 

SELECT * FROM users WHERE username = "root" AND password = "badpassword" or 1 = 1\"

 

that would grant that access to any  account. Here is what mysql_real_escape_string(); does

he enteres >badpassword" or 1=1\<

and here is what the query looks like after mysql_real_escape_string()

 

SELECT * FROM users WHERE username = "root" AND password = "badpassword\" or 1 = 1\\"

 

the added backslashes remove the breakout of your string input so that all of that is still in the string and not evaluated. it also nullifies the final backslash so that that backslash does not nullify your final quote and your query still gets executed

 

hopefully that made sense.

Link to comment
Share on other sites

Oh boy, my bad.

I thought this was the problem so I connected to my database earlier, but the mysql_real_escape_string() was one line before the connection...

 

Though the problem is now; does this infect characters as a '/' ?

 

It adds an escape character ('\') during data insertion/updating, but it shouldn't be visible during data retrieval.  If you do see an escape character during data retrieval, chances are you have magic quotes on, which is considered a no-no (if memory serves, it should be turned off by default in PHP5, and may be completely removed from the language when version 6 is finally released).

 

ussually mine returns the slashes with the data. stripslashes() should do the trick

Link to comment
Share on other sites

Oh boy, my bad.

I thought this was the problem so I connected to my database earlier, but the mysql_real_escape_string() was one line before the connection...

 

Though the problem is now; does this infect characters as a '/' ?

 

It adds an escape character ('\') during data insertion/updating, but it shouldn't be visible during data retrieval.  If you do see an escape character during data retrieval, chances are you have magic quotes on, which is considered a no-no (if memory serves, it should be turned off by default in PHP5, and may be completely removed from the language when version 6 is finally released).

 

So if I type in "what/ever" it returns "what\/ever" ?

Because I'm trying to implement it in my password, but the point is that my passwords get md5()'ed. And they get md5()'ed before they enter the mysql database.

 

So should I:

1) md5() the "\" with the password, so nevertheless my passwords containing slashes work

2) leave it like this, because md5() always returns Letters and numbers...

 

You're over thinking it.  The escape character doesn't remain in the db.  They're used only when the insertion/update happens, to make the query safe, and are then for all intents and purposes thrown away.  For a password, something like:

 

$pass = md5(mysql_real_escape_string($_POST['password']));

 

Would be fine for insertion.  And when obtaining user data:

 

$user = mysql_real_escape_string($_POST['username']);
$pass = md5(mysql_real_escape_string($_POST['password']));

$query = "SELECT * FROM users WHERE user_name = $user AND password = $pass";

 

Should suffice.

 

It's just like when you need to escape HTML output.  For example:

 

echo "<a href=\"http://www.google.com/\">Google</a>";

 

The escape characters marking the value of the href attribute aren't visible in the HTML that's generated.  The same thing applies with the database - you won't see the escape characters if you attempt to retrieve data.

Link to comment
Share on other sites

in terms of speed it would be faster just to have them in different files as your code wouldnt need to extract the $_GET variable, check it, if no move onto the next one and continue. It can load straight to that page. And its friendlier to search engines and hotlinking

 

Personally i think the site is alright. On the menu bar try and put a hover effect on. Its a bit offputting hovering over a nav link but then not telling if your actually able to click it or not. Maybe a light grey background on hover.

 

In terms of the pictures it might be worth looking up some way to stop them loading on page load until the users clicks a button to load them or something. Because, if someone has slow internet it could take quite a while for those pictures to load. Given that they are quite big.

 

But overall its alright

 

ps: Is all your family and such happy with those photo's all being public?

Link to comment
Share on other sites

in terms of speed it would be faster just to have them in different files as your code wouldnt need to extract the $_GET variable, check it, if no move onto the next one and continue. It can load straight to that page. And its friendlier to search engines and hotlinking

 

Personally i think the site is alright. On the menu bar try and put a hover effect on. Its a bit offputting hovering over a nav link but then not telling if your actually able to click it or not. Maybe a light grey background on hover.

 

In terms of the pictures it might be worth looking up some way to stop them loading on page load until the users clicks a button to load them or something. Because, if someone has slow internet it could take quite a while for those pictures to load. Given that they are quite big.

 

But overall its alright

 

ps: Is all your family and such happy with those photo's all being public?

 

I guess they don't mind the photos being public. At least I hope so. It's not as if the site has dozens of visitors, and it's only for the family itself so. I don't see why they'd mind something like that :P And if they would really mind, I'll not make them public or I'll delete their pictures if they would like. Thanks for the tip about the hovering!

Link to comment
Share on other sites

Personally i think the site is alright. On the menu bar try and put a hover effect on. Its a bit offputting hovering over a nav link but then not telling if your actually able to click it or not. Maybe a light grey background on hover.

 

About the hovering; If I put in in a greyish colour between the white of the ribbon and the grey from the background, it isn't really that pretty. Also, I made the ribbon in tables; so the "|" is also in a table, so if I use onmouseover it isn't that pretty eather..

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.