SitePoint Sponsor

User Tag List

Results 1 to 2 of 2
  1. #1
    SitePoint Member
    Join Date
    Mar 2000
    Location
    Indianapolis Indiana USA
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I am trying my best to develop a decent website from scratch. Although I have no technical backgroud, I nevertheless have been able to put together some decent pages. However I am developing two separate sub-sites which would require me to set permissions (IE: password access). I am bulding on FrontPage 98 and the web server intstalled in my computer is called Personal Web Server. Now, I am not exactly sure what it does mind you, but I have researched my inability to set permissions and found that, unless I misinterpreted something, Personal Web Server does not support the permissions function.

    So My Questions are:
    1. Did I make the correct interpretation?
    2. What does this web server do for me anyway? Do I need to get another one? If so, which one? (I am bulding my site and will transfer it FTP to Earthlink for hosting if that matters).

    Thanks in advance for any advice...I am trusting that this is a fairly easy problem to deal with, but I just don't know how.


    ------------------
    Mike Witsken

  2. #2
    Your Lord and Master, Foamy gold trophy Hierophant's Avatar
    Join Date
    Aug 1999
    Location
    Lancaster, Ca. USA
    Posts
    12,305
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    The following is an excerpt from the Personal Web Server 4.0's Help File:
    It is a little long.

    Securing an ASP Application
    You should not underestimate the importance of properly configured security settings. Besides exposing your ASP applications to unwanted tampering, poorly configured security settings can also keep intended users from accessing your .asp files.

    Your Web server offers you a variety of methods for securing your ASP based applications from unauthorized access and tampering. After you finish reading the security information outlined in this topic, take time to carefully review your Windows NT and Web server security documentation. For more information, see Security.

    NTFS Permissions
    You can secure your ASP application files by applying NTFS access permissions to individual files and directories. NTFS permissions, the foundation of your Web server's security system, define the various levels of file and directory access assigned to a user or group of users. When a user with a valid Windows NT account attempts to access a restricted file, your computer checks the file's Access Control List (ACL), which defines the permissions assigned various user accounts and groups. If the user's account has sufficient permissions to open the file, the computer grants access. For example, the owner of a Web application stored on your Web server will require Change permissions to view, alter, and delete the application's .asp files. However, public users accessing the same application, should only be assigned Read permissions, which enable those users to view, not alter, the application's Web pages.

    Securing the Global.asa
    To fully secure an ASP application, be sure to set NTFS file permissions for the appropriate user or group on your application’s Global.asa file. If your Global.asa includes commands that return information to the browser and you do not secure Global.asa, that information will be returned to the browser, even if the application’s other files are secured.

    For more information about configuring NTFS permissions, see Access Control.

    Note Be sure to apply NTFS permissions to an application's files in a consistent way . For example, if you inadvertently apply overly restrictive NTFS permissions to an include file required by your application, users may not be able to view or run the application. To prevent such problems, develop a careful plan for assigning NTFS permissions to your applications.

    Web Server Permissions
    You can configure your Web server's permissions to restrict how all users view, run, and manipulate your ASP pages. Unlike NTFS permissions, which provide granular control over the way specific users access your application files and directories, Web server permissions apply to all users, and do not discriminate between different types of user accounts.

    For users to run your ASP applications, you must use the following rules when setting Web server permissions:

    Enable the Read or Script permissions for virtual directories containing .asp files.
    Enable Read and Script permissions for virtual directories containing both .asp and other files, such as .html files, that contain scripts.
    Enable Read and Execute permissions for virtual directories containing both .asp and other executable files, such as .exe and .dll files, which require the Execute permission to run.
    For more information about configuring Web server permissions, see Access Control.

    Script-Mapped Files
    Application script-mapping ensures that your Web server will not accidentally download the source code for an .asp file. For example, even if you set Read permissions for a directory containing a particular .asp file, your Web server will not return that file's code to the user, as long as the .asp file belongs to a script-mapped application.

    Cookie Security
    ASP uses SessionID cookies to track information for specific Web browsers over the course of an application visit, or session. This means that an HTTP request with a matching cookie is assumed to have come from the same Web browser. Your Web server can use SessionID cookies to configure ASP applications with user-specific session information. For example, if your application is an online music store that enables users to select and purchase compact discs, then a SessionID might be used to track each a user's selections as the user wanders throughout the application.

    Can Vandals Guess the SessionID?
    To prevent computer vandals from guessing the SessionID cookie and gaining access to a legitimate user's session variables, your Web server assigns a randomly generated number to each SessionID. Whenever the user's Web browser returns a SessionID cookie, the server extracts the SessionID and the assigned number. The server then checks this number against a generated number, stored exclusively on the server. If the numbers match, the user obtains access to session variables. The effectiveness of this technique lies in the length of the assigned number (64-bits), which makes it highly unlikely that a computer vandal could hijack a user's active session by guessing the SessionID.

    Encrypting Sensitive SessionID Cookies
    A computer vandal, able to intercept a user's sessionID cookie, could use the cookie to impersonate that user. If an ASP application contains private information, a credit card or bank account number, then a vandal with a stolen cookie could start an active session on the application and access this information. You can prevent interception of SessionID cookies by encrypting the communication link between your Web server and the user's browser. For more information about encryption, see Security.

    Protecting Restricted ASP Content with Authentication
    You can require that every user attempting to access your restricted ASP content have a valid Windows NT account user name and password. Each time a user attempts access restricted content, your Web server authenticates, or confirms, the user's identity to ensure that the user has a valid Windows NT account.

    Your Web server supports several authentication methods including:

    Basic authentication Prompts users to enter user names and passwords.
    Windows NT Challenge/Response authentication Cryptographically obtains user identification information from the user's Web browser.
    However, your Web server will authenticate users only if you disable anonymous access or when the Windows NT File System permissions restrict anonymous access. For more information, see About Authentication.

    Protecting the Metabase
    ASP scripts that access the metabase require administrator privileges on the machine on which your Web server is running. When you execute these scripts from a remote machine, you must connect through an authenticated connection, such as a connection using the Windows NT Challenge/Response authentication method. You should create a server or directory for your administrative .asp files and set the directory security authentication method to Windows NT Challenge/Response for the server or directory. Currently, only Microsoft Internet Explorer, version 2.0 or later, supports Windows NT Challenge/Response authentication.

    Securing Applications with SSL
    The Secure Sockets Layer (SSL) 3.0 protocol, implemented as a Web server security feature, provides a secure virtually impervious way of establishing an encrypted communication link with users. SSL guarantees the authenticity of Web content and reliably verifies the identity of users accessing restricted Web sites.

    With SSL, you can require users attempting to access your ASP application to establish an encrypted communication link with your server; preventing the interception of sensitive information exchanged between the user and the application. For more information, see Encryption.

    Securing Included Files
    If you include a file that resides in an SSL-enabled directory from an .asp file that resides in an unsecured virtual root, SSL is not applied to the included file. Thus, to ensure that SSL is applied, be sure that both the including and the included files reside in SSL-enabled directories.

    Client Certificate Authentication
    A highly secure way regulate access to your ASP applications is to require users to log on with a client certificate. A digital identification containing information about the identity of the user, client certificates perform the same function as conventional forms of identification, such as a passport or driver's license. Users usually obtain client certificates from a trusted, third-party organization that verifies identification information before issuing a certificate. (Typically, these organizations will require a name, address, phone number, and organization name, however, the extent of this information can vary depending the level of identification assurance required from the certificate.)

    Whenever a user attempts to log on to an application requiring a certificate, the user's Web browser automatically forwards the certificate to the server. If your Web server's Secure Sockets Layer (SSL) certificate mapping features are properly configured, your server can authenticate the user before permitting access to an ASP application.

    ASP Scripts for Processing Certificates
    As an ASP application developer, you can write scripts to confirm the presence of a certificate and read certificate fields. For example, you can access the user name or company name fields from the certificate. Active Server Pages stores certificate information in the ClientCertificate collection of the Request object. For more information, see Built-in ASP Objects.

    Before you can process client certificates with ASP, however, your Web server must be configured to either accept or require a client certificate; otherwise the ClientCertificate collection will be empty.



    ------------------
    Wayne Luke
    WR Moderator
    Internet Media Provider


Bookmarks

Posting Permissions

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