Internet Information Server

Microsoft Internet Information Server is a Web server that enables you to publish information on a corporate intranet or on the internet. Internet Information server transmits information by using the Hypertext Transfer Protocol(HTTP). Internet Information server can also configured to provide File Tranfer Protocol(FTP) and gopher services. The FTP service enables users to transfer files to and from your Web site. The gopher service uses a menu-driven protocol for locating documents. The gopher protocol has been largely superseded by the HTTP protocol. Features of Internet Information Server The creative possibilities of what you can offer on an Internet Information server Web site are endless. Some familiar uses are to : o Publish a home page on the Internet for your business featuring a newsletter, sales information, or employment opportunities. o Publish a catalog and take orders from customers. o Publish interactive programs. o Provide your remote sales force easy access to your sales database. o Use an order-tracking database. Internet Information server - Working The Web is fundamentally a system of requests and responses. Web browsers request information by sending a URL to a Web server. The Web server responds by returning a Hypertext Markup Language(HTML) page. The HTML page canf be a static page that has already been formatted and stored in the Web stite, a page that the server dynamically creates in response to information provided by the user, or a page thata lists the available files and forlders on the Web site. Web Browser URL Request Every page on an intranet or on the Internet has a unique URL that identifies it. Web browsers request a page by sending a URL to a Web server. The server uses the information in the URL to locate and display the page. URL syntax is a specific sequesce of portocol, domain name, and path to the requested information. The protocol is the communication method used to gain access to information: for example, Hypertext Transfer Protocol(HTTP). Internet Information Server supports the HTTP, FTP, and gopher protocols. The domain name is Domain Name System(DNS) name of the computer that contains the information. The path is the path to the requested information on the computer. The following table shows examples of different URLs : A URL can also contain information that the Web server must process before returning a page. The data is added to end of the path. The Web server passes the data to a program or a script for processing and returns the results in a Web page. Example request types are listed in the following table: Web Server Response A Web server responds to a Web browser request by returning an HTML page. The returned page can be one of three types: a staic HTML page, a dyanamic HTML page, or a directory-listing page.

Static Pages Static pages are static HTML pages that are prepared in advance of the request. The Web server returns the HTML pages to the user, but takes no special action. The user requests a static page by typing in an URL (in the following illustration, http:\\www.company.com\home.htm) or by clicking a link pointing to an URL. The URL, request is sent to the server. The server responds by returning the static HTML page. Dynamic Pages Dynamic pages are created in response to a user's request. A Web browser collects information by presenting a page with text boxes, menus, and check boxes that the user fills in or selects. When the user clicks a button on a form, the data from the form is sent to the Web server. The server either passes the data to ascript or application to be processed, or it queries or posts data to adatabase. The server returns the results to the user in an HTML page. The following illustration shows how a user can send a query to Internet Server API(ISAPI) application that adds two numbers. The user types the two numbers to be added, then clicks a button, which in turn sends the two numbers to the Web server. The Web server calls the ISAPI application to add the numbers, then returns the results to the user in an HTML page. The following illustration shows a user posting an order to a databese using the Internet Database Connector. The user completes a form, then clicks a button, which in turn sends the data in the form to the server. The server posts the data to a database, then confirms the order by sending an HTML page. Directory Listing If users might send queries without specifying a particular file, you can either create a default document for a Web site or for a particular directory, or you can configure your server for directory browsing. If no default listing ( a hypertext version of a Windows Explorer or File manager listing) is returned to the user in the form of an HTML page. The user can then jump to the appropriate file by clicking it in the directory listing. Internet Information Server - Security Issues Internet Information Server is built on the Windows NT security model. Windows NT security helps you protes your computer and its resources by requiring assigned user accounts and passwords. You can control access to computer resources by limiting the user rights of these accounts. You can use the Windows NT File System (NTFS) to assign permissions to folders and files on your computer. You can control access to folders and files by preventing users from copying files to or from a folder, or by preventing users from executing files in certain folders. Advanced Issues to Consider When Designing Web Data Applications For performance and reliability reasons, it is strongly recommended that you use a client-server database engine for the deployment of data driven Web applications that require high-demand access from more than approximately 10 concurrent users. Although ADO works withany OLE DB compliant data source, it has been extensively tested and is designed to workwith client server databases such as Microsoft SQL Server or Oracle.ASP supports shared file databases (Microsoft Access or Microsoft FoxPro) as valid datasources. Although some examples in the ASP documentation use a

shared file database, it is recommended that these types of database engines be used only for development purposes orlimited deployment scenarios. Shared file databases may not be as well suited as client-server databases for very high-demand, production-quality Web applications. If you are developing an ASP database application intended to connect to a remote SQL Server database you should also be aware of the following issues: Choosing Connection Scheme for SQL Server You can choose between the TCP/IPSockets and Named Pipes methods for accessing a remote SQL Server database. WithNamed Pipes, database clients must be authenticated by Windows before establishing aconnection, raising the possibility that a remote computer running named pipes might denyaccess to a user who has the appropriate SQL Server access credentials, but does not havea Windows user account on that computer. Alternatively, connections using TCP/IP Socketsconnect directly to the database server, without connecting through an intermediarycomputeras is the case with Named Pipes. And because connections made with TCP/IPSockets connect directly to the database server, users can gain access through SQL Serverauthentication, rather than Windows authentication. ODBC 80004005 Error If the connection scheme for accessing SQL Server is not setcorrectly, users viewing your database application may receive an ODBC 80004005 errormessage. To correct this situation, try using a local named pipe connection instead of anetwork named pipe connection if SQL Server is running on the same computer as IIS.Windows XP security rules will not be enforced because the pipe is a local connection ratherthan a network connection, which can be impersonated by the anonymous user account.Also, in the SQL Server connection string (either in the Global.asa file or in a page-levelscript), change the parameter SERVER = server name to SERVER=(local) . The keyword(local) is a special parameter recognized by the SQL Server ODBC driver. If this solutiondoes not work, then try to use a non-authenticated protocol between IIS and SQL Server, such as TCP/IP sockets. This protocol will work when SQL Server is running locally or on remote computer. SQL Server Security If you use SQL Server's Integrated or Mixed security features, and the SQL Server database resides on a remote server, you will not be able to use integrated Windows authentication. Specifically, you cannot forward integrated Windows authentication credentials to the remote computer. This means that you may have to use Basic authentication, which relies on the user to provide user name and password information. Email The WebMail Helper: The WebMail Helper makes it easy to send an email from a web application using SMTP (Simple Mail transfer Protocol). Scenario: Email Support To demonstrate the use of email, we will create an input page for support, let the user submit the page to another page, and send an email about the support problem. First: Edit Your AppStart Page If you have built the Demo application in this tutorial, you already have a page called _AppStart.cshtml with the following content: _AppStart.cshtml

@{ WebSecurity.InitializeDatabaseConnection("Users", "UserProfile", "UserId", "Email", true); }

To initiate the WebMail helper, add the the following WebMail properties to your AppStart page: _AppStart.cshtml @{ WebSecurity.InitializeDatabaseConnection("Users", "UserProfile", "UserId", "Email", true); WebMail.SmtpServer = "smtp.example.com"; WebMail.SmtpPort = 25; WebMail.EnableSsl = false; WebMail.UserName = "support@example.com"; WebMail.Password = "password-goes-here"; WebMail.From = "john@example.com"; }

Properties explained: SmtpServer: The name the SMTP server that will be used to send the emails. SmtpPort: The port the server will use to send SMTP transactions (emails). EnableSsl: True, if the server should use SSL (Secure Socket Layer) encryption. UserName: The name of the SMTP email account used to send the email. Password: The password of the SMTP email account. From: The email to appear in the from address (often the same as UserName). Second: Create an Email Input Page Then create an input page, and name it Email_Input: Email_Input.cshtml <!DOCTYPE html> <html> <body> <h1>Request for Assistance</h1> <form method="post" action="EmailSend.cshtml"> <label>Username:</label> <input type="text name="customerEmail" /> <label>Details about the problem:</label>

<textarea name="customerRequest" cols="45" rows="4"></textarea> <p><input type="submit" value="Submit" /></p> </form> </body> </html> }

The purpose of the input page is to collect information, then submit the data to a new page that can send the information as an email. Third: Create An Email Send Page Then create the page that will be used to send the email, and name it Email_Send: Email_Send.cshtml @{ // Read input var customerEmail = Request["customerEmail"]; var customerRequest = Request["customerRequest"]; try { // Send email WebMail.Send(to:"someone@example.com", subject: "Help request from - " + customerEmail, body: customerRequest ); } catch (Exception ex ) { <text>@ex</text> } }

The IP Address The Internet Protocol moves data between hosts in the form of datagrams. Each datagram is delivered to the address contained in the Destination Address (word 5) of the datagram's header. The Destination Address is a standard 32-bit IP address that contains sufficient information to uniquely identify a network and a specific host on that network. An IP address contains a network part and a host part, but the format of these parts is not the same in every IP address. The number of address bits used to identify the network, and the number used to identify the host, vary according to the prefix length of the address. There are two ways the prefix length is determined: by address class or by a CIDR address mask. We begin with a discussion of traditional IP address classes.

Address Classes Originally, the IP address space was divided into a few fixed-length structures called address classes. The three main address classes are class A, class B, and class C. By examining the first few bits of an address, IP software can quickly determine the class, and therefore the structure, of an address. IP follows these rules to determine the address class:

If the first bit of an IP address is 0, it is the address of a class A network. The first bit of a class A address identifies the address class. The next 7 bits identify the network, and the last 24 bits identify the host. There are fewer than 128 class A network numbers, but each class A network can be composed of millions of hosts. If the first 2 bits of the address are 1 0, it is a class B network address. The first 2 bits identify class; the next 14 bits identify the network, and the last 16 bits identify the host. There are thousands of class B network numbers and each class B network can contain thousands of hosts. If the first 3 bits of the address are 1 1 0, it is a class C network address. In a class C address, the first 3 bits are class identifiers; the next 21 bits are the network address, and the last 8 bits identify the host. There are millions of class C network numbers, but each class C network is composed of fewer than 254 hosts. If the first 4 bits of the address are 1 1 1 0, it is a multicast address. These addresses are sometimes called class D addresses, but they don't really refer to specific networks. Multicast addresses are used to address groups of computers all at one time. Multicast addresses identify a group of computers that share a common application, such as a video conference, as opposed to a group of computers that share a common network. If the first four bits of the address are 1 1 1 1, it is a special reserved address. These addresses are sometimes called class E addresses, but they don't really refer to specific networks. No numbers are currently assigned in this range.

Luckily, this is not as complicated as it sounds. IP addresses are usually written as four decimal numbers separated by dots (periods). [1] Each of the four numbers is in the range 0-255 (the decimal values possible for a single byte). Because the bits that identify class are contiguous with the network bits of the address, we can lump them together and look at the address as composed of full bytes of network address and full bytes of host address. If the value of the first byte is: [1] Addresses are occasionally written in other formats, e.g., as hexadecimal numbers. However, the "dot" notation form is the most widely used. Whatever the notation, the structure of the address is the same.

Less than 128, the address is class A; the first byte is the network number, and the next three bytes are the host address. From 128 to 191, the address is class B; the first two bytes identify the network, and the last two bytes identify the host. From 192 to 223, the address is class C; the first three bytes are the network address, and the last byte is the host number. From 224 to 239, the address is multicast. There is no network part. The entire address identifies a specific multicast group. Greater than 239, the address is reserved. We can ignore reserved addresses.

cookie A cookie, also known as an HTTP cookie, web cookie, or browser cookie, is usually a small piece of data sent from a website and stored in a user's web browser while a user is browsing a website. When the user browses the same website in the future, the data stored in the cookie can be retrieved by the website to notify the website of the user's previous activity. Cookies were designed to be a reliable mechanism for websites to remember the state of the website or activity the user had taken in the past. This can include clicking particular buttons, logging in, or a record of which pages were visited by the user even months or years ago. Although cookies cannot carry viruses, and cannot install malware on the host computer, tracking cookies and especially third-party tracking cookies are commonly used as ways to compile long-term records of individuals' browsing histories a major privacy concern that prompted European and US law makers to take action in 2011. Other kinds of cookies perform essential functions in the modern Web. Perhaps most importantly, authentication cookies are the most common method used by web servers to know whether the user is logged in or not, and which account they are logged in under. Without such a mechanism, the site would not know whether to send a page containing sensitive information, or require the user to authenticate himself by logging in. The security of an authentication cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie's data to be read by a hacker, used to gain access to user data, or used to gain access (with the user's credentials) to the website to which the cookie belongs (see cross-site scripting and cross-site request forgery for examples). Session cookie A user's session cookie[13] (also known as an in-memory cookie or transient cookie) for a website exists in temporary memory only while the user is reading and navigating the website. When an expiry date or validity interval is not set at cookie creation time, a session cookie is created. Web browsers normally delete session cookies when the user closes the browser.[14][15] Persistent cookie A persistent cookie[13] will outlast user sessions. If a persistent cookie has its Max-Age set to 1 year, then, within the year, the initial value set in that cookie would be sent back to the server every time the user visited the server. This could be used to record a vital piece of information such as how the user initially came to this website. For this reason persistent cookies are also called tracking cookies. Secure cookie A secure cookie has the secure attribute enabled and is only used via HTTPS, ensuring that the cookie is always encrypted when transmitting from client to server. This makes the cookie less likely to be exposed to cookie theft via eavesdropping. HttpOnly cookie The HttpOnly cookie is supported by most modern browsers. [16][17] On a supported browser, an HttpOnly session cookie will be used only when transmitting HTTP (or HTTPS) requests, thus restricting access from other, non-HTTP APIs (such as JavaScript). This restriction mitigates but does not eliminate the threat of session cookie theft via cross-site scripting (XSS).[18] This feature applies only to sessionmanagement cookies, and not other browser cookies. Third-party cookie

First-party cookies are cookies set with the same domain (or its subdomain) as your browser's address bar. Third-party cookies are cookies set with domains different from the one shown on the address bar. The web pages on the first domain may feature content from a third-party domain, e.g. a banner advert run by www.advexample.com. Privacy setting options in most modern browsers allow you to block thirdparty tracking cookies. As an example, suppose a user visits www.example1.com, which includes an advert which sets a cookie with the domain ad.foxytracking.com. When the user later visitswww.example2.com, another advert can set another cookie with the domain ad.foxytracking.com. Eventually, both of these cookies will be sent to the advertiser when loading their ads or visiting their website. The advertiser can then use these cookies to build up a browsing history of the user across all the websites this advertiser has footprints on. Supercookie A "supercookie" is a cookie with a public suffix domain, like .com, .co.uk or k12.ca.us.[19] Most browsers, by default, allow first-party cookiesa cookie with domain to be the same or subdomain of the requesting host. For example, a user visiting www.example.com can have a cookie set with domain www.example.com or .example.com, but not .co.uk.[20] A supercookie with domain .com would be blocked by browsers; otherwise, a malicious website, likeattacker.com, could set a supercookie with domain .com and potentially disrupt or impersonate legitimate user requests to example.com. The Public Suffix List is a cross-vendor initiative to provide an accurate list of domain name suffixes changing.[21] Older versions of browsers may not have the most up-to-date list, and will therefore be vulnerable to certain supercookies. The term "supercookies" is sometimes used for tracking technologies that do not rely on HTTP cookies. Two such "supercookie" mechanisms were found on Microsoft websites: cookie syncing that respawned MUID cookies, and ETag cookies.[22] Due to media attention, Microsoft later disabled this code: In response to recent attention on "supercookies" in the media, we wanted to share more detail on the immediate action we took to address this issue, as well as affirm our commitment to the privacy of our customers. According to researchers, including Jonathan Mayer at Stanford University, "supercookies" are capable of re-creating users' cookies or other identifiers after people deleted regular cookies. Mr. Mayer identified Microsoft as one among others that had this code, and when he brought his findings to our attention we promptly investigated. We determined that the cookie behavior he observed was occurring under certain circumstances as a result of older code that was used only on our own sites, and was already scheduled to be discontinued. We accelerated this process and quickly disabled this code. At no time did this functionality cause Microsoft cookie identifiers or data associated with those identifiers to be shared outside of Microsoft. Zombie cookie Some cookies are automatically recreated after a user has deleted them; these are called zombie cookies. This is accomplished by a script storing the content of the cookie in some other locations, such as the local storage available to Flash content, HTML5 storages and other client side mechanisms, and then recreating the cookie from backup stores when the cookie's absence is detected. USES Session management

Cookies may be used to maintain data related to the user during navigation, possibly across multiple visits. Cookies were introduced to provide a way to implement a "shopping cart" (or "shopping basket"),[7][8] a virtual device into which users can store items they want to purchase as they navigate throughout the site. Shopping basket applications today usually store the list of basket contents in a database on the server side, rather than storing basket items in the cookie itself. A web server typically sends a cookie containing a unique session identifier. The web browser will send back that session identifier with each subsequent request and shopping basket items are stored associated with a unique session identifier. Allowing users to log in to a website is a frequent use of cookies. Typically the web server will first send a cookie containing a unique session identifier. Users then submit their credentials and the web application authenticates the session and allows the user access to services. Personalization Cookies may be used to remember the information about the user who has visited a website in order to show relevant content in the future. For example a web server may send a cookie containing the username last used to log in to a website so that it may be filled in for future visits. Many websites use cookies for personalization based on users' preferences. Users select their preferences by entering them in a web form and submitting the form to the server. The server encodes the preferences in a cookie and sends the cookie back to the browser. This way, every time the user accesses a page, the server is also sent the cookie where the preferences are stored, and can personalize the page according to the user preferences. For example, the Wikipedia website allows authenticated users to choose the webpage skin they like best; the Googlesearch engine once allowed users (even nonregistered ones) to decide how many search results per page they want to see. Tracking Tracking cookies may be used to track internet users' web browsing. This can also be done in part by using the IP address of the computer requesting the page or the referrer field of the HTTP request header, but cookies allow for greater precision. This can be demonstrated as follows: 1. If the user requests a page of the site, but the request contains no cookie, the server presumes that this is the first page visited by the user; the server creates a random string and sends it as a cookie back to the browser together with the requested page; 2. From this point on, the cookie will automatically be sent by the browser to the server every time a new page from the site is requested; the server sends the page as usual, but also stores the URL of the requested page, the date/time of the request, and the cookie in a log file. By analyzing the log file collected in the process, it is then possible to find out which pages the user has visited, in what sequence, and for how long.