what kind of security should be involved on websites

U

umcpgrad

2[H]4U
Joined
Apr 2, 2004
Messages
2,800
can someone educate me on what kind of security should be involved on websites and etc in terms of what steps can someone take to secure websites

thanks in advance
 
Secure what exactly? That's quite of a broad topic. Connection to the server? Passwords? Personal data? Credit card data? Emails? Authentication keys for external services? Front-end scripts? Etc., etc.
 
Based on the no capitalization, no punctuation nature of your post, I suggest you stick to static HTML pages with no javascript, database connections, or anything else besides html & images, hosted on a provider that handles all server maintenance for you.
 
Tawnos said:
Based on the no capitalization, no punctuation nature of your post, I suggest you stick to static HTML pages with no javascript, database connections, or anything else besides html & images, hosted on a provider that handles all server maintenance for you.
Click to expand...
I'll take this a step further and suggest he completely disconnect the server from any network.

Without any more information regarding the OPs query, it's the only surefire way to guarantee website security.
 
Probably the #1 rule of thumb: Or at least rather important...

Don't trust user data.

That means ANY data that comes from the browser or any remote connection.

For example you have a form with 4 options in a radio set called poll, let's just say A B C an D to be simple. You don't just take the value of $_POST['poll'] and throw it in the database. Nothing stops the user from sending something completely different. Then there's SQL injection. You want to ensure you escape special characters like quotes.

That's just scratching the surface. Stuff like the user agent and referrer are other examples of user data.

Oh and cookies. That's often overlooked.
 
Red Squirrel said:
Probably the #1 rule of thumb: Or at least rather important...

Don't trust user data.

That means ANY data that comes from the browser or any remote connection.

For example you have a form with 4 options in a radio set called poll, let's just say A B C an D to be simple. You don't just take the value of $_POST['poll'] and throw it in the database. Nothing stops the user from sending something completely different. Then there's SQL injection. You want to ensure you escape special characters like quotes.

That's just scratching the surface. Stuff like the user agent and referrer are other examples of user data.

Oh and cookies. That's often overlooked.
Click to expand...


Escape characters are still used? Isn't prepared query statements the best way to go?
 
Yeah but for someone just learning or for a very simple script it possibly would just be direct SQL queries being used, so it's still good to know what to do if submitting them that way.
 
Red Squirrel said:
Yeah but for someone just learning or for a very simple script it possibly would just be direct SQL queries being used, so it's still good to know what to do if submitting them that way.
Click to expand...

No, it's better to learn to do it right.
 
Red Squirrel said:
I guess most online tutorials/reference are wrong then.
Click to expand...

It is difficult to argue with an uncited claim, but yes it is wrong, and I've seen tutorials that are very old but still show high on the google search results. Most languages provide for creating parameterized prepared statements on the fly and it is far safer than concatenating a SQL query in code.

Tutorials should be demonstrating that method, direct query submission should be an advanced topic.
 
Red Squirrel said:
I guess most online tutorials/reference are wrong then.
Click to expand...

Yes, they are. I already PMed you about sql injection in code related to something else. Fact is, with parameterized queries, that injection vulnerability wouldn't exist.

There are areas like XSS and CSRF protection where you are forced into using escaping if you accept user input, but SQL is not a place you should be using unparameterized data - whether in application code or sql stored procedures.
 
Actually that code you pointed out is not vulnerable. It is something I originally considered and for some reason that I don't recall I encoded it in numerical values instead of escaping. Not the most efficient way but it worked till I could revisit it. TBH I did not even know about parameterized queries till now, had to google it, no tutorial I've read ever even mentioned it. There are however tutorials on it specifically but you have to know to actually look for it. So yeah I could have used that but did not know it even existed 3 years ago when I wrote the code.

I also noticed you were stalking me on quite a few websites, but, that's another topic that I don't want to throw in this thread.

I just saw everyone was being rude to OP so offered some basic help.
 
Red Squirrel said:
Actually that code you pointed out is not vulnerable. It is something I originally considered and for some reason that I don't recall I encoded it in numerical values instead of escaping. Not the most efficient way but it worked till I could revisit it. TBH I did not even know about parameterized queries till now, had to google it, no tutorial I've read ever even mentioned it. There are however tutorials on it specifically but you have to know to actually look for it. So yeah I could have used that but did not know it even existed 3 years ago when I wrote the code.

I also noticed you were stalking me on quite a few websites, but, that's another topic that I don't want to throw in this thread.

I just saw everyone was being rude to OP so offered some basic help.
Click to expand...

Lol, stalked you on multiple websites? I investigated a claim you made in another thread, and found the claim lacked evidence. Rather than call out that particular code on that thread, where it wasn't related to the question of the OP, I took it to PM. You make another claim in this thread, and here it's actually relevant.

OP, this is the _wrong_ chain of calls you want if you're trying to protect your data.

First, let's see how the table is created:
Code: 
res = m_connector.Query(String.Format("SET character_set_client = utf8;CREATE TABLE `{1}serializeobjects{0}` (`o_serial` bigint(20) unsigned NOT NULL,  `o_subtype` varchar(255) NOT NULL, `o_data` longtext NOT NULL,  PRIMARY KEY  (`o_serial`)) ENGINE=MyISAM DEFAULT CHARSET=latin1;",i,prefix));

Second, the SQL injection vulnerability:
Code: 
public int SaveDataEntry(SqlDataEntry entry,bool alreadyindb)
{

...

if(entry.IsBlank())
{
	queryret = Query(String.Format("DELETE FROM serializeobjects{0} WHERE o_serial='{1}' LIMIT 1;",entry.GetContainerId(),entry.GetSerial()));
}
else if(alreadyindb)
{
	queryret = Query(String.Format("UPDATE serializeobjects{0} set o_subtype='{1}', o_data='{2}' WHERE o_serial='{3}'",entry.GetContainerId(),entry.GetSubType(),entry.GetData(),entry.GetSerial()));
}
else 
{
	queryret = Query(String.Format("INSERT INTO serializeobjects{0}(o_serial,o_subtype,o_data)VALUES('{1}','{2}','{3}')",entry.GetContainerId(),entry.GetSerial(),entry.GetSubType(),entry.GetData()));
}

Look at the "else if" and "else" statements. Both are creating a sql query string using string-based query construction. I mentioned that both of those were vulnerable due to entry.GetData(). The relevant parts of that code:

Code: 
public class SqlDataEntry
{
...
    private string m_data;
...
    public string GetData()
    {
        return m_data;
    }

Lots of things use that, all of which can change your query string into something like
Code: 
"INSERT INTO serializeobjectsMobiles(o_serial,o_subtype,o_data)VALUES('1234','Mobile',''); DELETE FROM serializeobjectsMobiles; -- ha ha')"
 
Red Squirrel said:
I guess most online tutorials/reference are wrong then.
Click to expand...

Most of them are, and the reason why is that there are too many people out there whose perceived expertise is much, much greater than their actual expertise.

Don't listen to crap 'lern 2 program' sites if your goal is to know how to do things correctly.
 
You must log in or register to reply here.
Back
Top