Trying to test my sites security
Results 1 to 9 of 9

Thread: Trying to test my sites security

  1. #1
    Junior Member
    Join Date
    Mar 2003
    Posts
    1

    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.
    ا

  2. #2
    Senior Member
    Join Date
    Sep 2003
    Posts
    500
    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

    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

    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
    You shall no longer take things at second or third hand,
    nor look through the eyes of the dead...You shall listen to all
    sides and filter them for your self.
    -Walt Whitman-

  3. #3
    oldie ric-o's Avatar
    Join Date
    Nov 2002
    Posts
    487
    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.

  4. #4
    Senior Member
    Join Date
    Mar 2003
    Posts
    372
    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

    Give a man a match and he will be warm for a while, light him on fire and he will be warm for the rest of his life.

  5. #5
    Banned
    Join Date
    Jul 2001
    Posts
    1,100
    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

  6. #6
    Senior Member
    Join Date
    Aug 2003
    Posts
    1,019
    Do NOT install an AntiVirus program on your webserver.
    Since I am admittedly a moron, could you elaborate on this further?

  7. #7
    Banned
    Join Date
    Jul 2001
    Posts
    1,100
    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

    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

  8. #8
    oldie ric-o's Avatar
    Join Date
    Nov 2002
    Posts
    487
    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...
    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.

  9. #9
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,403
    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).
    Oliver's Law:
    Experience is something you don't get until just after you need it.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •