Trying to test my sites security

I made a pretty basic asp.net ecommerce website and i'm trying to test for sql injection attacks,XSS, all the rest of that crap. I don't know very much about security but i do know the basics. I was just wondering if anyone here knew of some tutorials or guides on how i can test and protect my site against these sorts of attacks. I'm using MS SQL for my db. All db calls are done using stored procs. I do also have some field validation. I would have liked to have been abel to post code or the site address but the Site isn't currently open to the public and i don't think my boss would approve. Again any information or tips would be much appreciated.

Thanks

P.S. Please forgive any lack of information or gramatical errors. I don't usually post.

First off, what operating system are you serving it off of (2K, 2003 server, yada, and more yada)
Make sure that you operating system itself is patched and secured. Next, make sure only the services you want running are running. Firewalls with good rules never hurt either. Finally Antivirus programs are a must.

You might be running off a nice big server, but all this will come into play if you are using a box for serving.

Okay now with the SQL. First and foremost, you want to make sure that any error in the database is sent back to the home page or to an error page. The way SQL crackers actually hack into your site is to read the errors generated by the database. If instead make sure that all of these errors are sent to a generic "Error" page or simply back home, the crackers job becomes signifigantly harder.
s
Next, don't use common table names! If you had a colum for say "users," instead of simply calling it "users" call it something else "Users_(hash 10292929)." Simply crackers will have a much harder time guessing that table than "users."

The finally thing that I can think of is to use the backslash trick. I have seen it on many sites I have tested for SQL injection. I can't explain how to do it, but the link below can. Basically, by adding a backslash to all the queries sent in, users won't be able to ovveride quotes. For example an input of 'union all select won't turn the request into

Quote:

---

SELECT '' FROM UNION ALL SELECT

---

That request I made prolly wasn't 100% correct, but here is the idea. Instead of requesting null, you instead would request

Quote:

---

SELECT '\' FROM UNION ALL SELECT

---

Instead of selecting everything, this will generate an error.

More on that is located here: http://www.openportals.com/index.php...tion%20Attacks

Here are some guides on what hackers are trying to do. If you follow the above advice, none of this will work

http://www.securiteam.com/securityre...DP0N1P76E.html

http://www.imperva.com/application_d...injection.html

In addition to LB's good tips/info there, have a couple things:

1) Validate all user input fields to protect against SQL injection and buffer overflows. Filter out stuff that could be used for SQL injection such as characters like ' " ( ). Check length and crop it off.

2) Current patch levels for not only O/S as LB stated but WEB APPLICATION SERVER! Make sure that it's fully patched as well. Too often people will run Cold Fusion or some other app server that's not current - bad.

3) Reinforce the error message *scrubbing* as LB said. Make all errors generic from not only the web server but application server (if present) as well. Too often the defaults are left making it REAL easy to detect what app server or database server you're running not to mention goodies such as database, table, and row names - gold mine for attacker!

3b) Don't forget to make login errors generic. I know this is basic and most people know this but I still find developers who tell the user whether the username or password was wrong rather than the proper way of saying something like "Login error".

4) Gotta say it: MAKE SURE YOU HAVE EXPLICIT APPROVAL/AUTHORITY TO PERFORM ANY TESTING FIRST before doing any. And get it in WRITING. Very important!

More very good links to read to help you understand how to pen-test your site...

* Penetration Testing for Web Applications (Part One) http://www.securityfocus.com/infocus/1704
* Penetration Testing for Web Applications (Part Two) http://www.securityfocus.com/infocus/1709
* Penetration Testing for Web Applications (Part Three) http://www.securityfocus.com/infocus/1722
* Common Security Vulnerabilities in e-commerce systems http://www.securityfocus.com/infocus/1775
* AppSecInc.com has a good section of whitepapers: http://www.appsecinc.com/techdocs/whitepapers.html
One of them is Hunting Flaws in Microsoft SQL Server White Paper http://www.appsecinc.com/presentatio...SQL_Server.pdf
* SQLSecurity.com has a some good free tools: http://www.sqlsecurity.com/

That'll keep ya busy for awhile. Enjoy.

Thanks guys, I just got handed a pen test for a web app for a company that we just bought. I have just started the basics on it and this is a most timely post. Thanks for the information and I'm going to go do some reading now :)

Quote:

---

Originally posted here by Lansing_Banda
Finally Antivirus programs are a must.

---

Do NOT install an AntiVirus program on your webserver. Bad bad bad bad bad bad bad idea.

Hrm, did I mention that it's a bad idea to install AntiVirus Software on a webserver? In case I forgot to mention it, this is a bad bad bad bad idea.

All of the other advice that you've been given sounds peachy to me though :hippy:

Quote:

---

Do NOT install an AntiVirus program on your webserver.

---

Since I am admittedly a moron, could you elaborate on this further?

Quote:

---

Originally posted here by groovicus
Since I am admittedly a moron, could you elaborate on this further?

---

Greetings:

Performance, plain and simple. A webserver that's got AntiVirus Software installed locally is going to cause a serious performance hit, especially on sites that allow file uploads (which is the main reason why you'd want AntiVirus for the webserver to begin with). You can also run into problems when a client is connecting to the webserver and trying to access a file that the AntiVirus software is trying to access at the same time.

Also, many websites store uploaded data in a database, and not as part of the file system. This can cause AntiVirus Software to never detect them at all. While you might not be infected, files uploaded and stored in your database may be, and you'll then pass them along to your users who are downloading those files. People will just LOVE you then :D

A MUCH better solution (and the only real solution in my eyes) when you're dealing with protecting servers from viruses, is to install a NETWORK AntiVirus solution that can monitor everything using its own dedicated resources.

Since your servers are firewalled appropriately (which they should be), and no one is surfing around websites or checking e-mail locally on the servers (which they should not be), the only real way you have to worry about viruses getting on the server is by users uploading them via features on your website that allow such things. And, this is EXACTLY where installing the AntiVirus Software locally will cause you problems.

There are products out there that claim to be made for webservers, but the ones I've evaluated are "clunky" to say the least, and they ALL cause performance hits for the server. Also, they all have the problem of not really being able to detect infected files stored in a database.

Network AntiVirus Software is your friend :bigpimp:

Lv4 & frosty1:
Have a couple more resources I found in doing my own research that you might find helpfull...

One Way Web Hacking by Saumil Shah: http://net-square.com/papers/one_way/one_way.html

OWASP Application Security FAQ: http://www.owasp.org/documentation/appsecfaq

OWASP Top 10 Vulnerabilities in Web Applications: http://www.owasp.org/documentation/topten
Summary...

Quote:

---

A1
Unvalidated Input
Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack backend components through a web application.

A2
Broken Access Control
Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users� accounts, view sensitive files, or use unauthorized functions.

A3
Broken Authentication and Session Management
Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users� identities.

A4
Cross Site Scripting (XSS) Flaws
The web application can be used as a mechanism to transport an attack to an end user�s browser. A successful attack can disclose the end user�s session token, attack the local machine, or spoof content to fool the user.

A5
Buffer Overflows
Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.

A6
Injection Flaws
Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

A7
Improper Error Handling
Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

A8
Insecure Storage
Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

A9
Denial of Service
Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.

A10
Insecure Configuration Management
Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.

---

OWASP, which stands for Open Web Aspplication Security Project, is a great resource of information as it's made up of web application developers and security experts working toward web application security goals. Check it out at http://www.owasp.org.

Quote:

---

Originally posted here by ric-o
1) Validate all user input fields to protect against SQL injection and buffer overflows. Filter out stuff that could be used for SQL injection such as characters like ' " ( ). Check length and crop it off.

---

Actually this is the wrong way to do it. The proper way would be to filter on the stuff you want/need and drop everything else (just like a firewall; allow what you know and kill the rest). You won't be the first who has the "too many slashes" syndrome or got bitten by someone that uses a different characterset (especially with UTF-8/Unicode).