Database Security & General Website Security Discussion

Gareth37

Hi,

I would like a discussion on database & general website/webhosting security.

A lot has been talked about SQL injection lately. What techniques do web programmers on here take to prevent this type of malicious damage?

Also, what other types of risks are associated with having databases etc.?

Thanks
G

Tom Dunne

Gareth37 wrote:

Hi,

I would like a discussion on database & general website/webhosting security.

Would you really?

And would you like us to actually do your homework for you too?

Gareth37

tom dunne wrote:

Would you really?

And would you like us to actually do your homework for you too?

Hi Tom. This is not homework. Yes Im learning some new things and I think it would be a benefit to many people doing similar things.

bonkey

Gareth37 wrote:

This is not homework. Yes Im learning some new things and I think it would be a benefit to many people doing similar things.

Well, lets treat it that way then...

Show/tell us what you have so far - what your perspective on the affair is.

Seth Brundle

Gareth37 wrote:

I would like a discussion on database & general website/webhosting security.

Thats nice. I'll join in so.

Gareth37 wrote:

A lot has been talked about SQL injection lately. What techniques do web programmers on here take to prevent this type of malicious damage?

Where was this talk?
Anyhow, as a web programmer, I design with this in mind which by not allowing it to arise in the first place! I store each record in its own database! Very messy but hopefully worth it in the end!

Gareth37 wrote:

Also, what other types of risks are associated with having databases etc.?

Don't let your DBs get too heavy (by storing each record in its own DB). If your DBs get too heavy you can damage your back carrying them around.

Evil Phil

kbannon wrote:

I store each record in its own database! Very messy but hopefully worth it in the end!

Not from a coding point of view, when you're writing myPL/T-SQL queries it does cut down on all those messy joins and stuff.

democrates

Gareth37 wrote:

Hi,

I would like a discussion on database & general website/webhosting security.

A lot has been talked about SQL injection lately. What techniques do web programmers on here take to prevent this type of malicious damage?

Also, what other types of risks are associated with having databases etc.?

Thanks
G

That's a colossal field of discussion but here's a tuppence worth. First off I wouldn't presume malice motivates every attempt to circumvent your protection, read on...

Databases on hosted servers (in good hosting companies) tend to be set up by people with a lot more security experience in that area than I so I can't talk to that and just trust them to do a good job.

The applications people like me develop can leave the door wide open though and so here are some practices I've adopted, some based on discussions here on boards.

1. Use SSH to store database access credentials in a file outside the web root to evade direct requesting. The file contains php statements which declare the host, database, user, and passcode as defined variables, these are eval'd by the requesting script.

2. Put database sql code in functions in a db include file which are tested to bits, I just call these from normal application code with an sql argument and if necessary a lastid return variable passed by reference.

3. Keep php/mysql error messages for maintenance eyes only and give the user a simple fail message with a reference code that only I can tanslate to a given error type. This frustrates weakness probing.

4. Never tell a user whether the username or passcode were wrong, this keeps the job of a brute force attack equal to the product of all possible usernames and all possible passcodes.

5. Use a dictionary to disallow passwords and only allow passcodes. Advise users on the page where they pick a passcode on good passcode creation methods. If your users will bear it have system generated passcodes only, random alphanum chars are best and wise for admins but pronounceable gibberish with alternating vowels and consonents make a fair compromise, though this reduces the workload for brute-force attacks.

6. Throttle registrations per hour and store newly registered emails in the database to frustrate your register form being used as a mail bomber.

7. Use sha1() to store the hash of passwords in the database, never the raw passwords.

8. Use random unique identifiers for entities such as users and other resources that have limited access, this makes it hard to make requests for resources you have no access to eg userid=1 is probably admin.

9. Distrust all external input eg from forms and cookies. Validate all input using the logic of accepting only allowed patterns rather than trying to keep an up to date list of bogeys.

10. Use mysql_real_escape_string() to avoid sql injection attacks.

11. Develop a solid role based access contol system with an admin interface to avoid recode risk for privilege changes. You probably won't do this on your first project but over time it will make sense to have a reliable reuseable facility.

12. Use session_regenerate() to create a new sessid whenever privilege escalation occurs or if paranoid for any logged in activity, this frustrates replay attacks and session hi-jacking.

13. Ideally use SSL for the secured areas, though the cost isn't always justified if the cost of hacking is more than the value of the data retreived or event triggered.

14. Read 2600 magazine, security books, and mainstream security websites, and buy the dvd freedom downtime from 2600.com to gain an appreciation for what the hacking community is really about and the real dark forces they actully help us to frustrate rather than lapping up the manure troweled out by mainsteam journalists and commentators eg Kevin Mitnick could launch a nuclear attack on the reds by whistling into a payphone.

15. Keep your own PC as secure as possible. Never play a Sony BMG CD on a microsoft pc, some of them install a rootkit to spy on you and open a back door for other attacks. Use freely available programs to protect against and remove if necessary keyloggers, viruses, etc. A keylogger can supply the crown jewels to the mystery visitor, from your admin passcode to your online banking credentials. Stay away from the darker corners of the net, particularly if you use IE as MS are widely despised in this community which values freedom. The approach of many hackers is that if you visit Sparta, bring a shield, not a pillow.

16. Never claim your site is secure. This is incorrect, arrogant, and an invitation to hackers to educate you and those to whom you made false claims.

Really there's too much to cover on a thread, security is an ongoing learning process and most of us are IT gnats compared to the hacker titans. We all hate spam, viruses, rootkits etc from black-hats be they government agencies, corporations, or criminals, but the key thing is to recognise the value of reduced risk we get from the white hat hackers who test systems, tip us off to vulnerabilities we didn't know we had, and often provide us with free counter-measures where source availability allows.

Gareth37

That is quite a bit there.

Some things i do myself is limit the referral pages to parsing scripts. So to stop people passing data to them from their own scripts.

What Im doing at the moment is taking in data from users and placing this data in a mysql database. All the data incoming is scanned for symbols like ' and $ etc.

Im using PERL: the scripts are stored in the cgi-bin on a dedicated web server on a hosting365.ie account.

1. Does the fact that the scripts are stored in the cgi-bin make the sytem more secure?

2. Does the fact that Im using a dedicated hosting account at hosting365 take away many of the security headaches?

My biggest worry is that someone could delete details, access accounts etc due to vunerablities in my PERL/MYSQL code. How difficult/easy in general are these types of cgi scripts accessed?

G

pH

Gareth37 wrote:

Some things i do myself is limit the referral pages to parsing scripts. So to stop people passing data to them from their own scripts.

When you say 'limit the referral pages' what exactly do you mean by that? because if it has anything to do with http referer then you're wasting your time, as the client send you this information and can send you anything that it wants.

So you haven't stopped anyone passing you data from their own scripts, and by fooling yourself into thinking that you have, you probably put your site at greater risk than if you'd have done nothing, as you may ignore other possible attacks believing that your referral limiting is protecting you.

Security is tough, and should really only be attempted once you understand exactly what the problems really are. Even well established/designed/tested products (say vBulletin or even recently ebay's forums) are regularly broken by determined hackers.

Gareth37

pH wrote:

When you say 'limit the referral pages' what exactly do you mean by that? because if it has anything to do with http referer then you're wasting your time, as the client send you this information and can send you anything that it wants.

So you haven't stopped anyone passing you data from their own scripts, and by fooling yourself into thinking that you have, you probably put your site at greater risk than if you'd have done nothing, as you may ignore other possible attacks believing that your referral limiting is protecting you.

Security is tough, and should really only be attempted once you understand exactly what the problems really are. Even well established/designed/tested products (say vBulletin or even recently ebay's forums) are regularly broken by determined hackers.

Yes that is a good point but its one more thing for the hacker to think about. He doesnt know that this is built in and may not suspect that it is.

democrates

Gareth37 wrote:

That is quite a bit there.

Some things i do myself is limit the referral pages to parsing scripts. So to stop people passing data to them from their own scripts.

What Im doing at the moment is taking in data from users and placing this data in a mysql database. All the data incoming is scanned for symbols like ' and $ etc.

Im using PERL: the scripts are stored in the cgi-bin on a dedicated web server on a hosting365.ie account.

1. Does the fact that the scripts are stored in the cgi-bin make the sytem more secure?

2. Does the fact that Im using a dedicated hosting account at hosting365 take away many of the security headaches?

My biggest worry is that someone could delete details, access accounts etc due to vunerablities in my PERL/MYSQL code. How difficult/easy in general are these types of cgi scripts accessed?

G

1. Check out http://perl.apache.org/ for info on mod_perl, the perl community by and large seem to prefer it for web apps rather than running through cgi...

2. If it's managed by hosting365 they have the headaches, if you have to config it all yourself you have the headaches. Personally I'd leave system security to the people doing it all day every day and focus on the application end. A shared hosting account is more secure than a dedicated server badly configured by an inexperienced user.

Assuming the server is sound, I think your biggest worry ought to be around the applications you run, these are where most attacks will focus as honeypots have found. SSL is advised if you have sensitive data. Check out http://en.wikipedia.org/wiki/Computer_security for some good links.

NutJob

When a security hole is reported doing something about it.

Sounds obvious i know but i reported a site to its owner as having sql injection flaws and xss flaws and the site has not been fixed and that was 6 months ago.

As for hardening the server that's a big area.

Server Side:
Disabling the SA account

-Running SQl server/mysql/others as a limited user with as few a privileges as possible

-Locking down tables like sysobjects(Delay tactic by this stage its two late)

-Firewalling the server to only allow connections from the web app the SUS server/update repository + the admins pc(or VPN).

-Disabling all unnecessary services.

-plenty of scripts out there for locking down IIS

-Bastille for linux.

-running with a minimal set of apps (seems to apply to linux/unix only)

-for the crazy Compile linux with ASR patches (PAX)

-Trusted BSD:eek: is worth a concideration

-Snort IDs

-Tripwire or others


App Side:
-Testing the application as this will most likely be the Point of entry
-XSS
-Sql injection
-Xpath injection
-remote includes
-Privilege escalation
-Session guessing
-Information disclosure

As for perl CGI
The biggest problems your going to face is sanitising input and output. Because your dealing with user input usually shelling stuff to a unix shell, watching for pipes.

What i usually do is use a regular expression to limit user input to [a-zA-Z][0-9][._@]
Watch what values are being passed by the program.
Never trust anything being passed to the application from the client
-referrer links
-Form fields
-Cookies
-Watch error handling doesn't tell anyone anything about the application bar "Sorry there was an error processing ur req..............."

Read up on secure code and secure development practices.
look at old exploits and learn from them they will show you exactly what not to do.


The big ones:
-Updating the software when flaws come out
-Education of developers and admins



Like the energiser bunny the list just goes on and on (and iv missed lots).

This is where cost benefit analysis kicks in (plus common sense).

Seth Brundle

Seeing as how this thread has become serious I may as well offer something useful.

* The golden rule is to not allow anything user originated to get near the system if it has not been cleansed.
Different server side languages will use different methods but by escaping all special characters into their HTML equivalents should be the first step. Possibly overkill but I also encode SQL keywords (SELECT, DELETE, UNION, etc.)
If possible use stored procedures or parameterised queries.
Special data should also be encrypted. Passwords shuld have a random 'salt' value appended onto them and then encrypted. Store a copy of the unencrypted salt for later use. This helps against a dictionary attack.
* All data should be validated before it is executed against the database.
* Limiting database access with a least privilege user should always be applied.
* Hide error messages from the user!

Read up on SQL injection and while you are at it read up on email injection as the principles are the same.

Gareth37

Thanks for the tips.

I seen that email injection is a problem.

I would like to find out more about encrypting passwords. Any links?

Thanks,
G

Seth Brundle

Is Google down?

democrates

kbannon wrote:

Is Google down?

I nearly went and checked.:eek: