Ask a Question related to ASP.NET Security, Design and Development.

  1. #1

    Default Hosting security

    Hello.

    This is probably a well knows issue but I still cannot find a
    solution.

    I have noticed that it is possible to read web.config files inside
    other directories on the same server simply opening them using a aspx
    script.
    This could allow my users to steal each other username and passwords.

    What is the correct way to handle this problem?

    Thanks
    Alain Guest

  2. Similar Questions and Discussions

    1. Picture Hosting Security
      What is the best software program that would give me the same functionality as www.wireimage.com where photographers can upload pictures to my site...
    2. Important: Web Hosting from $2.95/m - Reseller Hosting from $9.95/m
      ::*CRUCIAL PARADIGM *:: * AFFORDABLE, RELIABLE, PROFESSIONAL WEB SOLUTIONS *Linux Hosting * ' Compare Plans'...
    3. Security tool to check CGI scripts for security holes/vulnerabities
      I'm searching for a good security tool that I can use regularly to scan all the programs/scripts in my web servers cgi-bin directory to identify...
    4. Security issues with Asp.Net in Shared Hosting Environments
      Dear Asp.Net Security Community Over the last couple of months I have posted several items in the official Asp.Net website (www.asp.net) related...
    5. ASP.Net shared hosting & security
      Hello. I'm trying to setup a Win2003 server for hosting ASP.Net Applications in a Shared Hosting enviroment. With the "old" ASP I created a...
  3. #2

    Default Re: Hosting security

    First of all, it's best to encrypt your passwords in some way. Even better
    is to store them in a database somewhere. The asp.net runtime will not post
    a .config file back to the user, but it is vulnerable to being read by an
    aspx script, which is intentional. If your server scripts couldn't read the
    configuration, then the configuration wouldn't be very valuable. So, the
    obvious solution is to not give your users access to drop their own scripts
    onto your server - why would you have something like this enabled in the
    first place?

    --
    Chris Jackson
    Software Engineer
    Microsoft MVP - Windows XP
    Windows XP Associate Expert
    --
    "Alain" <alain@camping.it> wrote in message
    news:1078089d.0310080150.2dd4b748@posting.google.c om...
    > Hello.
    >
    > This is probably a well knows issue but I still cannot find a
    > solution.
    >
    > I have noticed that it is possible to read web.config files inside
    > other directories on the same server simply opening them using a aspx
    > script.
    > This could allow my users to steal each other username and passwords.
    >
    > What is the correct way to handle this problem?
    >
    > Thanks

    Chris Jackson Guest

  4. #3

    Default Re: Hosting security

    > First of all, it's best to encrypt your passwords in some way. Even better
    > is to store them in a database somewhere. The asp.net runtime will not post
    > a .config file back to the user, but it is vulnerable to being read by an
    > aspx script, which is intentional.
    I know its intentional. That is exactly the problem.
    > why would you have something like this enabled in the
    > first place?
    I work for a little service provider. Some of the user require the
    possibility to run dynamic applications.
    In the past the company relied on COM+ objects which loaded
    configurations from external udl files. The udl files were not
    readable in any way by the users.
    Alain Guest

  5. #4

    Default Re: Hosting security

    > This is probably a well knows issue but I still cannot find a
    > solution.
    >
    > I have noticed that it is possible to read web.config files inside
    > other directories on the same server simply opening them using a aspx
    > script.
    > This could allow my users to steal each other username and passwords.
    In addition to the suggestion of encrypting username and passwords in the
    web.config file, don't put them in the web.config file, but store them in a
    database, and have the database password protected.

    Lauchlan M


    Lauchlan M Guest

  6. #5

    Default Re: Hosting security

    If your users have the ability to drop executable code in the same
    application directory, there isn't much you can do. Anything that your
    application can use to decrypt, their application can use to decrypt. Your
    only hope is security through obscurity, which is not security at all. You
    could try using the aspnet_setreg tool to encrypt, and you can try using a
    database connection (which, if your application can use it, theirs can too)
    so it's not quite as obvious, but what you are describing is a truly
    unsecurable scenario that needs to be rearchitected. You may want to
    consider using Windows authentication, if that is an option.

    --
    Chris Jackson
    Software Engineer
    Microsoft MVP - Windows XP
    Windows XP Associate Expert
    --
    "Alain" <alain@camping.it> wrote in message
    news:1078089d.0310082332.6d29783b@posting.google.c om...
    > > First of all, it's best to encrypt your passwords in some way. Even
    better
    > > is to store them in a database somewhere. The asp.net runtime will not
    post
    > > a .config file back to the user, but it is vulnerable to being read by
    an
    > > aspx script, which is intentional.
    >
    > I know its intentional. That is exactly the problem.
    >
    > > why would you have something like this enabled in the
    > > first place?
    >
    > I work for a little service provider. Some of the user require the
    > possibility to run dynamic applications.
    > In the past the company relied on COM+ objects which loaded
    > configurations from external udl files. The udl files were not
    > readable in any way by the users.

    Chris Jackson Guest

  7. #6

    Default Re: Hosting security

    Dear Alain

    The problems that you are describing are very real and Asp.Net by
    default is vulnerable to them

    The solution is to implement website isolation as described in this
    article: "http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/plan/appisoa.asp"

    I would also call to your attention the new Open source Security tool
    that we (in ddplus)have published which allow you to test your server
    agaist these (and other) security problems.

    See this post for more details on ANSA (Asp.Net Security Analyser)
    "http://groups.google.com/groups?q=asp.net+security+group:microsoft.public.d otnet.framework.aspnet.security&hl=en&lr=&ie=UTF-8&oe=UTF-8&group=microsoft.public.dotnet.framework.aspnet.s ecurity&selm=701fd6b6.0310072039.5820b34c%40postin g.google.com&rnum=2"
    or go directly to it's GotDotNet workspace:
    "http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id=36ae9a2c-8740-4b52-924e-320edf64fba5"

    Hope this helps

    Best regards

    Dinis Cruz
    ..Net Security Consultant
    DDPlus ([url]www.ddplus.net[/url])

    [email]alain@camping.it[/email] (Alain) wrote in message news:<1078089d.0310080150.2dd4b748@posting.google. com>...
    > Hello.
    >
    > This is probably a well knows issue but I still cannot find a
    > solution.
    >
    > I have noticed that it is possible to read web.config files inside
    > other directories on the same server simply opening them using a aspx
    > script.
    > This could allow my users to steal each other username and passwords.
    >
    > What is the correct way to handle this problem?
    >
    > Thanks
    Dinis Cruz Guest

  8. #7

    Default Re: Hosting security

    Thanks Dinis!
    Thas it exactly what I was looking for.
    Alain Guest

Posting Permissions

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139