Student Assignments

ASSIGNMENT ON:Create a digital certificate & install it using java key tool.
Try to setup & use the ssl protocol using this for a sample web page using tomcat as the web server Create Digital Certificate
What is Digital Certificate? A digital certificate is an electronic "credit card" that establishes your credentials when doing business or other transactions on the Web. It is issued by a certification authority (CA). It contains your name, a serial number, expiration dates, a copy of the certificate holder's public key (used for encrypting messages and digital signatures), and the digital signature of the certificateissuing authority so that a recipient can verify that the certificate is real. Some digital certificates conform to a standard, X.509. Digital certificates can be kept in registries so that authenticating users can look up other users' public keys. How to Create Digital Certificate? Step 1: Go Run Menu (Press Start Menu & go to Run Option) Type: MMC (Microsoft Management Console)
Step 2: Open Window of MMC (Microsoft Management Console) Under the File menu, choose Add/Remove Snap in.
Step 3: Go to Add, then from the Add Standalone Snap-in panel choose Certificates, and click Add.
Step 4: Press on Add Button & select Certificate & Press Add Button.
Step 5: Select Computer Account.
Step 6: Close the snap-in panel, clicking OK
Step 7: Certificate Created. At the bottom of the General tab, click the "Install Certificate..." button. This will start the certificate import wizard. Click "Next".
Getting a Thawte test SSL certificate
Step 1: Create a keystore with a private/public keypair. keytool -genkey -keyalg "RSA" -keystore keystore -storepass 123456 validity 360 Step 2: Create a Certificate Signing Request (CSR). This will be sent to the CA when a certificate or certificate chain is requested. keytool -certreq -keyalg "RSA" -file my.host.com.csr -keystore keystore
User firstname lastname: - Make this your website name - www.sitm.com Organization: - Your company name - SITM Organizational Unit: - Your company's domain name www.sitm.com City/Locality: - Your city - Pune State: - Your state, capitalize this - Maharashtra Country: - The 2 letter code for country India Step 3:
Paste the contents of the .csr file generated in step 2 into the text area on this page. Note that the form is sensitive to linebreaks, and cut&paste may fail with certain browsers.
Step 4:
Set the validity to the number of days you specified with generating the keypair on the thawte page. Step 5: Set the certificate to be "Valid from now" Step 6: Get a "Test SSL Chained CA Cert". This will make sure that you get a whole certificate chain and will not have to add the CA's root certificate yourself to create a certificate chain.
Step 7: For the other options, the defaults should be fine and you can click the "Generate Test Certificate" Step 8: Take the resulting certificate and paste it into a file called my.host.com.cer, again, note that the cert is sensitive to linebreaks, and cut&paste may fail with certain browsers. Step 9: Now store the certificate in your keystore: keytool -keystore keystore -keyalg "RSA" -import -trustcacerts -file my.host.com.cer
Setting up a secure website using HTTPS in Orion
Configuring a secure website can be done through the following steps: Step1: Copy the default-web-site.jsp config in the /config directory to secureweb-site.jsp and open it with a text editor.
Step 2: Add secure="true" as an attribute to the tag. Add the keystore to the main body.
Step 3: Make Login Page.
Code of Login Page (index.jsp)
<%@ include file="connection.jsp" %> <%@ page contentType="text/html; charset=iso-8859-1" language="java" import="java.sql.*" errorPage="" %> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <web-site display-name="Default Orion WebSite" secure="true"> <default-web-app application="default" name="defaultWebApp" /> <access-log path="../log/default-web-access.log" /> <ssl-config keystore="../keystore" keystore-password="123456" /> </web-site> <html> <head> <title>Wel Come to JSP Page</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <style type="text/css"> <!-@import url("../stylesheet/main.css"); --> </style>
</head> <FORM action="login" method="post"> <P><font size="2"> <INPUT TYPE="HIDDEN" NAME="REQUEST" VALUE="index.html"> <INPUT TYPE="HIDDEN" NAME="AREA" VALUE="management"> Username: <INPUT type="TEXT" name="USER" maxlength="50" size="6"><BR> Password: <INPUT type="PASSWORD" name="PASSWORD" maxlength="50" size="6"><BR> <input type="checkbox" name="REMEMBER" value=""> Remember password?<br> <br><INPUT type="submit" value="Login"> </font></P> </FORM> </html>
General SSL debugging
Step 1: There are a few ways to get some more verbose debug information from the JSSE implementation. java -Djavax.net.debug=help -jar orion.jar
Step 2: if you want to turn on full verbosity, use: java -Djavax.net.debug=all -jar orion.jar
Security Management Assignment E-Mail Security

Email Security
Electronic mail (email) is perhaps the most popularly used system for exchanging business information over the Internet (or any other computer network). At the most basic level, the email process can be divided into two principal components: (1) mail servers, which are hosts that deliver, forward, and store email; and (2) mail clients, which interface with users and allow users to read, compose, send, and store email. This document addresses the security issues of mail servers and mail clients, including Web-based access to mail.
Mail servers and user workstations running mail clients are frequently targeted by attackers. Because the computing and networking technologies that underlie email are ubiquitous and well-understood by many, attackers are able to develop attack methods to exploit security weaknesses. Mail servers are also targeted because they (and public Web servers) must communicate to some degree with untrusted third parties. Additionally, mail clients have been targeted as an effective means of inserting malware into machines and of propagating this code to other machines. As a result, mail servers, mail clients, and the network infrastructure that supports them must be protected.
Examples of email security issues include the following:
1)To exchange email with the outside world, a requirement for most organizations, it is allowed through organizations network perimeter defenses. At
a basic level, viruses and other types of malware may be distributed throughout an organization via email. Increasingly, however, attackers are getting more sophisticated and using email to deliver targeted zero-day attacks in an attempt to compromise users workstations within the organizations internal network.
2)Given emails nature of human to human communication, it can be used as a social engineering vehicle. Email can allow an attacker to exploit an organizations users to gather information or get the users to perform actions that further an attack.
3)Flaws in the mail server application may be used as the means of compromising the underlying server and hence the attached network. Examples of this unauthorized access include gaining access to files or folders that were not meant to be publicly accessible, and being able to execute commands and/or install software on the mail server.
4)Denial of service (DoS) attacks may be directed to the mail server or its support network infrastructure, denying or hindering valid users from using the mail server.
5)Sensitive information on the mail server may be read by unauthorized individuals or changed in an unauthorized manner.
6)Sensitive information transmitted unencrypted between mail server and client may be intercepted. All popular email communication standards default to sending usernames, passwords, and email messages unencrypted.
7)Information within email messages may be altered at some point between the sender and recipient.
8)Malicious entities may gain unauthorized access to resources elsewhere in the organizations network via a successful attack on the mail server. For example, once the mail server is compromised, an attacker could retrieve users
passwords, which may grant the attacker access to other hosts on the organizations network.
9)Malicious entities may attack external organizations from a successful attack on a mail server host.
Gmail
By default, Gmail uses an unencrypted connection to retrieve user data, encrypting only the connection used for the login page. However, by changing the URL from http://mail.google.com/mail/ to https://mail.google.com/mail/, Gmail can be told to use a secure connection, reducing the risk of third-party eavesdropping on users' information, such as emails and contacts, which are transmitted in plaintext as JavaScript data in the page source code. POP3 and IMAP access uses Transport Layer Security, or TLS. Although TLS is used when one sends email via an email client such as Mozilla Thunderbird, it is not used when the email is sent from the Gmail servers to the destination domain's mail exchangers, unless supported, so at some stage the user's email message may still be transmitted in unencrypted plain text.
Gmail offers a spam filtering system. According to Gmail, messages marked as spam are automatically deleted after 30 days, but there have been reports on Gmail Help Discussion of spam mails staying in the spam folder for months. However, Gmail has now fixed this problem.[citation needed] The spam filtering system cannot be disabled. POP3 users need to check their Spam folder manually via the web interface as only emails sent to the Inbox can be retrieved via POP3.
IP addresses of Gmail users are disguised in order to protect security [17].
All incoming and outgoing e-mails are automatically scanned for viruses in email attachments. If a virus is found on an attachment the reader is trying to open, Gmail will try to remove the virus and open the cleaned attachment. Gmail also scans all outgoing attachments and will prevent the message from being sent if a virus is found. Executable files are automatically blocked by the Anti-Virus system. However, some viruses have been known to hide from the scanner and have infiltrated many e-mails.[citation needed] Gmail also does not allow users to send or receive executable files or archives containing executable files. Gmail is also one of the first major e-mail providers to sign outgoing mails with Yahoo!'s DomainKeys signatures. In the past, Gmail has had severe trouble with security which allowed a full account compromise via Cross-Site Scripting (XSS) vulnerabilities affecting the Google.com homepage or information disclosure through a file which was stored on Google's server and included all the Email contacts of the currently logged in user.The vulnerability was quickly patched after the initial disclosures on the Internet.
Web-Based Mail Access

Web-based mail applications, also known as Webmail applications, are increasingly being used as a means of email service delivery, because Web browsers that enable access to the client are available on nearly every Internetenabled device. A user simply runs a Web browser and connects to a Web site that hosts the Web-based mail application. The connection is made using either Hypertext Transfer Protocol (HTTP) or HTTP over Transport Layer Security (TLS), also known as HTTPS. HTTPS encrypts the communications, which protects both authentication information and email message content. HTTP alone does not offer any protection, so organizations should consider using HTTPS for Web-based mail application communications.
Web-based mail applications incorporate much of the mail-handling functionality of traditional mail clients and communicate with their associated mail servers using the same mailbox access protocols described earlierSMTP, POP, and IMAP, as well as proprietary protocols. The mailbox access protocols
are used between the Web servers and mail servers only; the protocols are not carried between the Web servers and Web browsers.
Yahoo Mail And Hot Mail

With banking, anonymizer.com, or other SSL-secured web sites, they maintain the SSL session so your traffic remains encrypted. That doesn't have to be that way, however. In Yahoo Mail's case, the login page is SSL secured. Once you are done with the secured login, you no longer have an SSL session anymore. Look for the padlock icon in the status bar. It is there on the login page (if you pick the https:// URL for the login page) but it is NOT there once you are on the webmail pages. If you used the SSL login page, you get redirected to a non-SSL page after the login has been submitted.
Note that SSL could still be used even when the current page is not SSL-secured, by submitting form data to a SSL-secured page. I believe that is how Hotmail's login page works. When you login to Hotmail, you are on a Passport.net page and there is no padlock icon in the status bar (because you don't yet have an SSL session). When you click the Sign In button, the action="https://login.passport.com/ppsecure/post.srf clause for the <form> tag directs the data for the form with your login credentials gets sent to the HTTPS page. So you aren't SSL secure for the login page but the credentials are submitted to an SSL-secured page (i.e., from the non-SSL page rendered locally in your browser, you enter the data and click Submit, your browser connects to the HTTPS site for an SSL session, and then the credentials are sent encrypted to that other page). I did not see any HTML for Yahoo Mail's Compose web page that would submit form data to an SSL-secured page or site, so the absence of the padlock icon in the browser's status bar means you are NOT on a secure page when composing and sending your message. Your login can be secured but your message contents are not.
Personally I prefer seeing the padlock icon to know if SSL is still in use. That gives a visual clue as to your security. Submitting form data from a non-secure page (rendered locally) which then has it sent to an SSL secured page or site means you don't know if the transmit is secure unless you look at the HTML code. I suppose that submitting form data to an SSL page is cheaper than allocating SSL
resources up front and pending them until you complete the login, but that leaves you in the dark as to how secure are your login credentials. My bank always establishes an SSL session and it persists so that I continually see the padlock icon during my session. They do that deliberately to let you know you have a secure connection. Yahoo doesn't need to do that, even when using their web mail interface, since they are only securing your login, not your message content. Same for Hotmail. If you don't see the padlock icon showing you have a current SSL session, you'll have to check the HTML code to verify form data gets submitted to an https:// page.
MD5 uses the SMTP commands in the session between the e-mail client and the SMTP server (i.e., Javascript is not used). I wasn't sure how Yahoo Mail did it for the freebie accounts that do not provide POP3/SMTP servers. From Pidgorny's posts and some Googling, yep, it seems Javascript get sent from the server to handle the MD5 processing, but hopefully the server on each login sends a different randomized key. You can see the MD5 parameters in the URL that Yahoo sends to you when using MD5 (if you log the HTTP session). That's why I'm not sure YahooPOPs bothers to run the Javascript that gets sent by the server for the MD5 secured login. I thought the key sent by the server was a parameter in the URL returned to the client (Yahoo Pops). I thought that MD5 also only encrypted the password and not the username whereas SSL encrypts both; however, the username is included in outbound e-mails, anyway, and since that is plain text than any sniffer could get the username.
Outside an organization that is geographically distributed, especially across a WAN, where IPsec makes sense, I haven't heard nor experienced any public sites across the Internet that provide IPsec support. Most end users have trouble figuring out how to configure the e-mail client for non-SSL (i.e., standard) connections, some may use an SSL connect, if available, and few even bother with x.509 or PGP certificates for digital signing or encryption, so I doubt IPsec is something that gets embraced for services to the typical nondescript user community. IPsec seems mostly used for same-LAN host-to-host connection (client/server and peer-to-peer), WAN connects between routers and gateways, for dial-up clients, and Internet access from private networks. I haven't seen IPsec used for any e-mail or web mail services. Wouldn't IPsec actually require access to the hardware or hosts on which IPsec was enabled (so you can load the driver and manage the policies)? Well, banks and other secured sites are often hosted by contracted web host providers so the client never has access to the hosts to modify their networking configuration and policies. A bank doesn't want to
redesign their web page or manage the web hosting provider's networking should they switch to a different web-hosting provider. Using security at the application level, like SSL, means the client who ultimately provides the services of that site retains control over security. The web-hosting provider obviously isn't going to let their customers monkey around with their network configuration and policies and let customers mangle their IPsec setup.
Assignment on COOKIES
Q. Study the topic of cookies. Are cookies a threat to security? Why? What are the solutions to this?
Cookies
A very small text file placed on computer hard drive by a Web Page server. It is essentially our identification card, and cannot be executed as code or deliver viruses. It is uniquely ours and can only be read by the server that gave it to us. The main purpose of a cookie is to tell the server that you returned to that Web page. If we talk to a typical surfer, we'll find one of their biggest fears is of this horrible thing called a cookie. Cookies are so dangerous, such a huge security risk that anyone would be foolish to even consider letting one within a mile of him. In actuality, cookies are harmless. All they are is a simple bit of text, which web sites use to identify a surfer in some manner. This could be as simple as a numeric character saying, "this is Pranab", or in some cases it can contain actual email addresses, phone numbers or addresses - BUT ONLY IF THESE WERE ENTERED BY THE SURFER. Cookies can be very wonderful as, properly used, they can personalize the surfing experience making it that much more profitable and enjoyable. Perhaps the main real danger of a cookie is that it records what has been surfed. For example, if we surfed to a site called "yahoo.com", you might get a cookie file named "pranab@yahoo.com". Pranab might have to think fast if he doesnt wants his cookie directory to be examined by others. Generally, cookies are extremely valuable. Sometimes they may let others know more about what you've been doing than you desire. The recommendation is, to find a good cookie management product and install it on your computer. Then selectively accept or decline cookies from specific sites as you are asked. cookies, more commonly referred to as web cookies or just cookies, are parcels of text sent by a server to a web browser and then sent back unchanged by the browser each time it accesses that server. HTTP cookies are used for authenticating, tracking, and maintaining specific information about users, such as site preferences or the contents of their electronic shopping carts. The term "cookie" is derived from "magic cookie," a well known
concept in UNIX computing which inspired both the idea and the name of HTTP cookies. Cookies have been of concern for Internet privacy, since they can be used for tracking browsing behavior. Cookies have also been criticized because the identification of users they provide is not always accurate and because they could potentially be a target of network attackers. Some alternatives to cookies exist, but each has its own uses, advantages and drawbacks. In fact, cookies are simple pieces of data unable to perform any operation by themselves. In particular, they are neither spyware nor viruses, despite the detection of cookies from certain sites by many anti-spyware products. Most modern browsers allow users to decide whether to accept cookies, but rejection makes some websites unusable. For example, shopping baskets implemented using cookies do not work if cookies are rejected. Cookies are threat for security? Why? Up to crtain extent yes, cookies are the threats to security. Because, besides privacy concerns, cookies also have some technical drawbacks. In particular, they do not always accurately identify users, they can be used for security attacks, and they are at odds with the Representational State Transfer (REST) software architectural style.
15.0.1 15.0.2 Inaccurate identification

If more than one browser is used on a computer, each usually has a separate storage area for cookies. Hence cookies do not identify a person, but a combination of a user account, a computer, and a Web browser. Thus, anyone who uses multiple accounts, computers, or browsers has multiple sets of cookies. Likewise, cookies do not differentiate between multiple users who share a computer and browser, if they do not use different user accounts.
Cookie Hijacking
A cookie can be stolen by another computer that is allowed reading from the networkDuring normal operation, cookies are sent back and forth between a server (or a group of servers in the same domain) and the computer of the browsing user. Since cookies may contain sensitive information (user name, a token used for authentication, etc.), their values should not be accessible to other computers. Cookie theft is the act of intercepting cookies by an unauthorized party. Cookies can be stolen via packet sniffing in an attack called session hijacking. Traffic on a network can be intercepted and read by computers on the network other than its sender and its receiver, (particularly on unencrypted public Wi-Fi networks.) This traffic includes cookies sent on ordinary unencrypted http sessions. Where network traffic is not encrypted, malicious
users can therefore read the communications of other users on the network, including their cookies, using programs called packet sniffers. This issue can be overcome by securing the communication between the user's computer and the server by employing Transport Layer Security (https protocol) to encrypt the connection. A server can specify the secure flag while setting a cookie; the browser will then send it only over a secure channel, such as an SSL connection. However a large number of websites, although using secure https communication for user authentication (i.e. the login page), subsequently send session cookies and other data over ordinary unencrypted http connections for performance reasons. Hackers can therefore easily intercept the cookies of other users and impersonate them on the relevant websites.
Cross-site scripting:
A cookie that should be only exchanged between a server and a client is sent to another party. A different way to steal cookies is cross-site scripting and making the browser itself send cookies to servers that should not receive them. Modern browsers allow execution of pieces of code retrieved from the server. If cookies are accessible during execution, their value may be communicated in some form to servers that should not access them. Encrypting cookies before sending them on the network does not help against this attack. This type of cross-site scripting is typically exploited by attackers on sites that allow users to post HTML content. By embedding a suitable piece of code in an HTML post, an attacker may receive cookies of other users. Knowledge of these cookies can then be exploited by connecting to the same site using the stolen cookies, thus being recognised as the user whose cookies have been stolen. A way for preventing such attacks is by the HttpOnly flag; this is a Microsoft option that makes a cookie inaccessible to client side script. However, website designers should consider designing their websites so that they are immune to cross-site scripting. Cookie poisoning: an attacker sends a server an invalid cookie, possibly modifying a valid cookie it previously received from the server.
15.0.3 Cookie poisoning

While cookies are supposed to be stored and sent back to the server unchanged, an attacker may modify the value of cookies before sending them back to the server. If, for example, a cookie contains the total value a user has to pay for the items in their shopping basket, changing this value exposes the server to the risk of making the attacker pay less than the supposed price. The process of tampering with the value of cookies is called cookie poisoning, and is sometimes used after cookie theft to make an attack persistent. In cross-site cooking, the attacker exploits a browser bug to send an invalid cookie to a server. Most websites, however, only store a session identifier a randomly generated unique number used to identify the user's session in the
cookie itself, while all the other information is stored on the server. In this case, the problem of cookie poisoning is largely eliminated.
15.0.4 Cross-site cooking

Each site is supposed to have its own cookies, so a site like evil.net should not be able to alter or set cookies for another site, like good.net. Cross-site cooking vulnerabilities in web browsers allow malicious sites to break this rule. This is similar to cookie poisoning, but the attacker exploits non-malicious users with vulnerable browsers, instead of attacking the actual site directly. The goal of such attacks may be to perform session fixation. Users are advised to use the more recent versions of web browsers in which such issue is mitigated.
15.0.5 Inconsistent state on client and server

The use of cookies may generate an inconsistency between the state of the client and the state as stored in the cookie. If the user acquires a cookie and then clicks the "Back" button of the browser, the state on the browser is generally not the same as before that acquisition. As an example, if the shopping cart of an online shop is realized using cookies, the content of the cart may not change when the user goes back in the browser's history: if the user presses a button to add an item in the shopping cart and then clicks on the "Back" button, the item remains in the shopping cart. This might not be the intention of the user, who possibly wanted to undo the addition of the item. This can lead to unreliability, confusion and bugs. The website designers should therefore be aware of this issue and implement measures to handle such situation as fits.
What is the solution for this?
From Clients side Cookies can be blocked using the settings in the web browser
Alternatives to cookies Some of the operations that can be realised using cookies can also be realised using other mechanisms. However, these alternatives to cookies have their own drawbacks, which make cookies usually preferred to them in practice. Most of the following alternatives allow for user tracking, even if not as reliably as cookies. As a result, privacy is an issue even if cookies are rejected by the browser or not set by the server.
IP address
An unreliable technique for tracking users is based on storing the IP addresses of the computers requesting the pages. This technique has been available since the introduction of the World Wide Web, as downloading pages requires the server holding them to know the IP address of the computer running the browser or the proxy, if any is used. This information is available for the server to be stored regardless of whether cookies are used or not. However, these addresses are typically less reliable in identifying a user than cookies because computers and proxies may be shared by several users, and the same computer may be assigned different Internet addresses in different work sessions (this is often the case for dial-up connections). The reliability of this technique can be improved by using another feature of the HTTP protocol: when a browser requests a page because the user has followed a link, the request that is sent to the server contains the URL of the page where the link is located. If the server stores these URLs, the path of page viewed by the user can be tracked more precisely. However, these traces are less reliable than the ones provided by cookies, as several users may access the same page from the same computer, NAT router, or proxy and then follow two different links. Moreover, this technique only allows tracking and cannot replace cookies in their other uses. Tracking by IP address can be impossible with some systems that are used to retain Internet anonymity, such as Tor. With such systems, not only could one browser carry multiple addresses throughout a session, but multiple users could appear to be coming from the same IP address, thus making IP address use for tracking wholly unreliable. Some major ISPs, including AOL, route all web traffic through a small number of proxies which makes this scheme particularly unworkable.
URL (query string) A more precise technique is based on embedding information into URLs. The query string part of the URL is the one that is typically used for this purpose, but other parts can be used as well. The PHP session mechanism uses this method if cookies are not enabled. This method consists of the Web server appending query strings to the links of a Web page it holds when sending it to a browser. When the user follows a link, the browser returns the attached query string to the server. Query strings used in this way and cookies are very similar, both being arbitrary pieces of information chosen by the server and sent back by the browser. However, there are some differences: since a query string is part of a URL, if that URL is later reused, the same attached piece of information is sent to the server. For example, if the
preferences of a user are encoded in the query string of a URL and the user sends this URL to another user by e-mail, those preferences will be used for that other user as well. Moreover, even if the same user accesses the same page two times, there is no guarantee that the same query string is used in both views. For example, if the same user arrives to the same page but coming from a page internal to the site the first time and from an external search engine the second time, the relative query strings are typically different while the cookies would be the same. For more details, see query string. Other drawbacks of query strings are related to security: storing data that identifies a session in a query string enables or simplifies session fixation attacks, referer logging attacks and other security exploits. Transferring session identifiers as HTTP cookies is more secure.
Hidden form fields A form of session tracking, used by ASP.NET, is to use web forms with hidden fields. This technique is very similar to using URL query strings to hold the information and has many of the same advantages and drawbacks; and if the form is handled with the HTTP GET method, the fields actually become part of the URL the browser will send upon form submission. But most forms are handled with HTTP POST, which causes the form information, including the hidden fields, to be appended as extra input that is neither part of the URL, nor of a cookie. This approach presents two advantages from the point of view of the tracker: first, having the tracking information placed in the HTML source and POST input rather than in the URL means it will not be noticed by the average user; second, the session information is not copied when the user copies the URL (to save the page on disk or send it via email, for example). A drawback of this technique is that session information is in the HTML code; therefore, each web page must be generated dynamically each time someone requests it, placing an additional workload on the web server.
[HTTP authentication As for authentication, the HTTP protocol includes the basic access authentication and the digest access authentication protocols, which allow access to a Web page only when the user has provided the correct username and password. If the server requires such credential for granting access to a Web page, the browser requests them to the user; once obtained, the browser stores and uses them also for accessing subsequent pages, without requiring the user to provide them again. From the point of view of the
user, the effect is the same as if cookies were used: username and password are only requested once, and from that point on the user is given access to the site. In the basic access authentication protocol, a combination of username and password is sent to the server in every browser request. This means that someone listening in on this traffic can simply read this information and store for later use. This problem is overcome in the digest access authentication protocol, in which the username and password are encrypted using a random nonce created by the server.
Macromedia Flash Local Stored Objects If a browser includes the Macromedia Flash Player plugin, the Local Shared Objects functionality can be used in a way very similar to cookies. Local Stored Objects may be an attractive choice to web developers because a majority of Windows users have Flash Player installed, the default size limit is 100 kB, and the security controls are distinct from the user controls for cookies, so Local Shared Objects may be enabled when cookies are not. The major drawback with this approach is the same as every platform/vendor-specific approach: it breaks the web's global accessibility and interoperability, tying up web development to a specific client's platform, excluding users who use standardscompliant web user agents and instead forcing them to use platform/vendor-specific web agents, which propitiates vendor lock-in.
Client-side persistence Some web browsers support a script-based persistence mechanism that allows the page to store information locally for later retrieval. Internet Explorer, for example, supports persisting information in the browser's history, in favorites, in an XML store, or directly within a Web page saved to disk. If JavaScript is enabled, the window .name property of the object window can be used to persistently store data. This property remains unaltered across the loading and unloading of other web pages. However, this method introduces a security risk, as the user may decide to then go to a site different than the intended one, and that site would be able to see the data.
A different mechanism relies on browsers normally caching (holding in memory instead of reloading) JavaScript programs used in web pages. As an example, a page may contain a link such as <script type="text/javascript" src="example.js">. The first time this page is loaded, the program example.js is loaded as well. At this point, the program remains cached and is not reloaded the second time the page is visited. As a result, if this program contains a statement such as id=3243242, this identifier remains valid and can be exploited by other JavaScript code the next times the page is loaded, or another page linking the same program is loaded.
Study of Ethical Hacking Tools

Introduction
The explosive growth of the Internet has brought many good things: electronic commerce, easy access to vast stores of reference material, collaborative computing, e-mail, and new avenues for advertising and information distribution, to name a few. As with most technological advances, there is also a dark side: criminal hackers. Governments, companies, and private citizens around the world are anxious to be a part of this revolution. But,they are afraid that some hacker will break into their Web server and replace their logo with pornography, read their e-mail, steal their credit card number from an on-line shopping site, or implant software that will secretly transmit their organization's secrets to the open Internet. With these concerns and others, the ethical hacker can help.
15.0.6 What is ethical hacking?

An ethical hacking is where a computer and network expert who attacks a security system on behalf of its owners, seek vulnerabilities that a malicious hacker could exploit. To test a security system, ethical hacking uses the same methods as their less principled counterparts, but report problems instead of taking advantage of them. Ethical hacking is also known as penetration testing, intrusion testing, and red teaming. Individuals involved in ethical hacking are sometimes called a white hat, a term that comes from old Western movies, where the "good guy" wore a white hat and the "bad guy" wore a black hat. One of the first examples of ethical hacking at work was in the 1970s, when the United States government used groups of experts called red teams to hack its own computer systems. According to Ed Skoudis, Vice President of Security Strategy for Predictive Systems' Global Integrity consulting practice, ethical hacking has continued to grow in an otherwise lackluster IT industry, and is becoming increasingly common outside the government and technology sectors where it began. Many large companies, such as IBM, maintain employee teams of ethical hackers.
Few of the Ethical Hacking tools studied by us are as follows: CAIN & ABEL Cain & Abel is a password recovery tool for Microsoft Operating Systems. It allows easy recovery of various kind of passwords by sniffing the network, cracking encrypted passwords using Dictionary, Brute-Force and Cryptanalysis attacks, recording VoIP conversations, decoding scrambled passwords, recovering wireless network keys, revealing password boxes, uncovering cached passwords and analyzing routing protocols Cain & Abel has been developed in the hope that it will be useful for network administrators, teachers, security consultants/professionals, forensic staff, security software vendors, professional penetration tester and everyone else that plans to use it for ethical reasons. The author will not help or support any illegal activity done with this program. Be warned that there is the possibility that you will cause damages and/or loss of data using this software and that in no events shall the author be liable for such damages or loss of data. Cain & Abel is a two part program distributed at http://www.oxid.it as a Self-Installing executable package named "ca_setup.exe". Cain (Cain.exe) is the main GUI application, Abel is a Windows service composed by two files: Abel.exe and Abel.dll.
Cain is the first part of the program. Developed with a simple Windows graphical user interface, its main purpose is to concentrate several hacking techniques and proof of concepts providing a simplified tool focused on the recovery of passwords and authentication credentials from various sources.
The user interface is made up of lists, tabs, toolbars and dialogs. Lists are used to contain similar kind of information such as passwords, host names, hashes and other parameters while tabs are used to switch from features. The sniffer toolbar contains only two buttons to activate/deactivate the sniffer and APR functions and the main toolbar the remaining commands to interact with the program. Note The blue "+" and the recycle bin buttons on the main toolbar have the general mean to "add something to" and "remove something from" the current list but they performs different actions depending on the currently focused list. There are also some general Hot Keys in the program to accelerate some functions: Insert -> Add to List, Insert new entry, new item ....... Delete -> Remove selected items from the current list, Remove all ..... Alt+Del -> Hide Cain's main window Alt+PgDwn -> Send Cain's main window to system tray Cain is compiled using Microsoft Visual C++ and linked as a single executable file named "Cain.exe". Although it is principally written in C/C++ a lot of code has been optimized in
Assembler for performance reasons. MFC classes and OpenSSL libraries are statically linked to the program; this increases the file size but eliminates the need to distribute shared DLLs.
15.0.7 Abel
Abel is the second part of the program. Designed as a Windows NT service it is composed by two files "Abel.exe" and "Abel.dll"; the first is the main service executable program and the second is a library that contains some required functions. Although Cain is the main Abel's frontend, it is not needed to be installed for Abel to work. The service can be installed locally or remotely (using Cain) and requires Administrator's privileges on the target machine. Abel communicates with Cain using the Windows named pipe "\\computername\pipe\abel" and it can accept connections from multiple hosts at the same time. All data transmitted over this pipe is encrypted using the RC4 symmetric encryption algorithm and the fixed key "Cain & Abel". This is done only to scramble the traffic sent on the network and not to hide program's intentions. The service runs using the Local System account and provides some interesting features like the Remote NT Hashes Dumper, the Remote LSA Secrets Dumper and the Remote Console.
15.0.8 Remote Console

Abel's remote console provides a system shell on the remote machine. The Abel service runs on the remote machine in the security context of it's Local System Account; every command sent to the console is executed with the same access privileges of that account.
You can use the Abel console to add users, enumerate networks, ping remote hosts, map network drives and so on .... every command is executed on the Abel-side.
Features:
Password Crackers Password Crackers can be found in the program under the "Cracker" sub tab. The tree on the left allows you to select the list containing desired encrypted passwords or hashes to crack. Those selected are then loaded into the Dictionary / Brute-Force dialog using the relative function within the list pop up menu. Brute-Force Password Cracker Brute-Force attack is method of breaking a cipher (that is, to decrypt a specific encrypted text) by trying every possible key. Feasibility of brute force attack depends on the key length of the cipher, and on the amount of computational power available to the attacker. Cain's Brute-Force Password Cracker tests all the possible combinations of characters in a pre-defined or custom character set against the encrypted passwords loaded in the brute-force dialog. The key space of all possible combination of passwords to try is calculated using the following formula: KS = L^(m) + L^(m+1) + L^(m+2) + ........ + L^(M) where L = character set length m = min length of the key and M = max length of the key.
Dictionary Password Cracker A dictionary attack consists of trying "every word in the dictionary" as a possible key for an encrypted password. A dictionary of potential passwords is more accurately known as a wordlist. This kind of attack is generally more efficient than a brute-force attack, because users typically choose poor passwords. There are two methods of improving the success of a dictionary attack: the first method is to use a larger dictionary, or more dictionaries (technical dictionaries and foreign language dictionaries will increase the overall chance of discovering the correct password); the second method is to perform string manipulation on the dictionary.
It also remembers each dictionary file position reached to resume from previous attacks (the Reset button cleans the start position of the wordlists).
Cryptanalysis This feature enables password cracking using the Faster Cryptanalytic time memory trade off method introduced by Philippe Oechslin. This cracking technique uses a set of large tables of pre-calculated encrypted passwords, called Rainbow Tables, to improve the trade-off methods known today and to speed up the recovery of clear text passwords.
It is fully compatible with the well known software RainbowCrack by Zhu Shuanglei, the first software implementation of the above algorithm, and supports Rainbow Tables for the following hashing/encryption algorithms: LM, FastLM, NTLM, CiscoPIX, MD2, MD4, MD5, SHA-1, SHA-2 (256), SHA-2 (384), SHA-2 (512), MySQL (323), MySQL (SHA1), RIPEMD160. Rainbow Tables can be generated using the "rtgen.exe" program, included with RainbowCrack, or the Windows "winrtgen" utility available at www.oxid.it. This cracking technique is pretty fast however it is useful to crack only some kind of encrypted passwords only. Please note that the majority of modern network protocols already use the challenge-response mechanism so, generally speaking, this attack is not suitable for password hashes captured from the network; on the contrary it is really effective to crack straight hashes often used to store encrypted passwords locally Box Revealer
This feature can reveal the passwords stored behind the asterisks in standard password text-boxes.
How it works:
It uses the "DLL injection" technique to run a thread in the same security context of the Local Security Authority Subsystem process. Once injected and executed the thread will run with the same access privileges of the Local Security Authority Subsystem; it loads the function "DumpBox" from Abel.dll which enumerates every password text-box present on the screen and dumps its text (the password) into a temporary file named boxes.txt. Finally, the content of this file is put on the screen and the temporary file is deleted. The "Box Revealer" supports most standard password text-boxes, however some applications don't store passwords behind the asterisks for security reasons. In such cases this feature will not be able to show the passwords.
Network Mapper
Nmap (Network Mapper) is an open source tool for network exploration and security auditing. It was designed to rapidly scan large networks, although it works fine against single hosts. Nmap uses raw IP packets in novel ways to determine what hosts are available on the network, what services (application name and version) those hosts are offering, what operating systems (and OS versions) they are running, what type of packet filters/firewalls are in use, and dozens of other characteristics. While Nmap is commonly used for security audits, many systems and network administrators find it
useful for routine tasks such as network inventory, managing service upgrade schedules, and monitoring host or service uptime. The output from Nmap is a list of scanned targets, with supplemental information on each depending on the options used. Key among that information is the interesting ports table. That table lists the port number and protocol, service name, and state. The state is either open, filtered, closed, or unfiltered. Open means that an application on the target machine is listening for connections/packets on that port. Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed. Closed ports have no application listening on them, though they could open up at any time. Ports are classified as unfiltered when they are responsive to Nmap's probes, but Nmap cannot determine whether they are open or closed. Nmap reports the state combinations open|filtered and closed|filtered when it cannot determine which of the two states describe a port. The port table may also include software version details when version detection has been requested. When an IP protocol scan is requested (sO), Nmap provides information on supported IP protocols rather than listening ports. In addition to the interesting ports table, Nmap can provide further information on targets, including reverse DNS names, operating system guesses, device types, and MAC addresses. Usage: nmap [Scan Type(s)] [Options] {target specification} Everything on the Nmap command-line that isn't an option (or option argument) is treated as a target host specification. The simplest case is to specify a target IP address or hostname for scanning. Target Specification: Sometimes you wish to scan a whole network of adjacent hosts. For this, Nmap supports CIDR-style addressing. You can append /numbits to an IP address or hostname and Nmap will scan every IP address for which the first numbits are the same as for the reference IP or hostname given. For example, 192.168.10.0/24 would scan the 256 hosts between 192.168.10.0 (binary: 11000000 10101000 00001010 00000000) and 192.168.10.255 (binary: 11000000 10101000 00001010 11111111), inclusive. 192.168.10.40/24 would do exactly the same thing.
Host Discovery Host discovery needs are diverse, so Nmap offers a wide variety of options for customizing the techniques used. Host discovery is sometimes called ping scan, but it goes well beyond the simple ICMP echo request packets associated with the ubiquitous ping tool. Users can skip the ping step entirely with a list scan (-sL) or by disabling ping (-PN), or engage the network with arbitrary combinations of multi-port TCP SYN/ACK, UDP, and ICMP probes. The goal of these probes is to solicit responses which demonstrate that an IP address is actually active (is being used by a host or network device). By default, Nmap does host discovery and then performs a port scan against each host it determines is online.
15.1 Service and Version Detection

Point Nmap at a remote machine and it might tell you that ports 25/tcp, 80/tcp, and 53/udp are open. Using its nmap-services database of about 2,200 well-known services, Nmap would report that those ports probably correspond to a mail server (SMTP), web server (HTTP), and name server (DNS) respectively. This lookup is usually accuratethe vast majority of daemons listening on TCP port 25 are, in fact, mail servers. After TCP and/or UDP ports are discovered using one of the other scan methods, version detection interrogates those ports to determine more about what is actually running. The nmapservice-probes database contains probes for querying various services and match expressions to recognize and parse responses. Nmap tries to determine the service protocol (e.g. FTP, SSH, telnet, http), the application name (e.g. ISC BIND, Apache httpd, Solaris telnetd), the version number, hostname, device type (e.g. printer, router), the OS family (e.g. Windows, Linux) and sometimes miscellaneous details like whether an X server is open to connections. When Nmap receives responses from a service but cannot match them to its database, it prints out a special fingerprint and a URL for you to submit if to if you know for sure what is running on the port. Due to the open nature of n-map, these submissions so that your find can benefit everyone.
15.2 OS Detection
One of Nmap's best-known features is remote OS detection using TCP/IP stack fingerprinting. Nmap sends a series of TCP and UDP packets to the remote host and examines practically every bit in the responses.
Nmap compares the results to its nmap-os-db database of more than 800 known OS fingerprints and prints out the OS details if there is a match. Each fingerprint includes a freeform textual description of the OS, and a classification which provides the vendor
name (e.g. Sun), underlying OS (e.g. Solaris), OS generation (e.g. 10), and device type (general purpose, router, switch, game console, etc). If Nmap is unable to guess the OS of a machine, and conditions are good (e.g. at least one open port and one closed port were found), Nmap will provide a URL you can use to submit the fingerprint if you know (for sure) the OS running on the machine. By doing this you contribute to the pool of operating systems known to Nmap and thus it will be more accurate for everyone.
OS detection enables several other tests which make use of information that is gathered during the process anyway. One of these is uptime measurement, which uses the TCP timestamp option (RFC 1323) to guess when a machine was last rebooted. This is only reported for machines which provide this information. Another is TCP Sequence Predictability Classification. This measures approximately how hard it is to establish a forged TCP connection against the remote host. It is useful for exploiting source-IP based trust relationships (rlogin, firewall filters, etc) or for hiding the source of an attack.
15.3 Output
Any security tools is only as useful as the output it generates. Complex tests and algorithms are of little value if they aren't presented in an organized and comprehensible fashion. Given the number of ways Nmap is used by people and other software, no single format can please everyone. So Nmap offers several formats, including the interactive mode for humans to read directly and XML for easy parsing by software. In addition to offering different output formats, Nmap provides options for controlling the verbosity of output as well as debugging messages. Output types may be sent to standard output or to named files, which Nmap can append to or clobber. Output files may also be used to resume aborted scans. Nmap makes output available in five different formats. The default is called interactive output, and it is sent to standard output (stdout). There is also normal output, which is similar to interactive except that it displays less runtime information and warnings since it is expected to be analyzed after the scan completes rather than interactively. XML output is one of the most important output types, as it can be converted to HTML, easily parsed by programs such as Nmap graphical user interfaces, or imported into databases. The two remaining output types are the simple grepable output which includes most information for a target host on a single line, and sCRiPt KiDDi3 0utPUt.
By: Syndicate 7 Kartik Fozdar (07020541017) Dinkar Tripathi (07020541015) Vikas Chhimpa (07020541012) Devender Singh (07020541035) V.Sharanya (07020541043)
Study and examine how password security of Gmail, Hotmail and yahoo work? Both client and Server side.
Introduction of Password enabled security: The most important phase in e-mail password security is during the formation of a new e-mail id. At the time of new id formation all data except the password is passed on to the server in plain text. The password is sent in encrypted form using message digest algorithm. The data once it reaches the server is stored in an encrypted form wherein the data is stored for the use of every user. Also some unique security features against spamming is provided in the form being filled by the user where a character string is to be replicated by the user. This is done in order to avoid spamming by generating lot of useless fake e-mail ids. The variation from the basic password authentication is not to use the password itself, but to use something derived from the password. We can run certain algorithm on the password and sore the output in the database. Afterwards the user enters the password and the user computer performs the same algorithm locally and sends the derived password to the server, where it is verified. These requirements closely match those of a message digest, so an algorithm such as MD5 or SHA-1 is used. A bit of randomness is added so that the exchange of information between the users computer and the server is never the same. This will ensure that the replay attack is foiled. This is done by the user sending only the login request only with the user id. The server in turn checks the user login id and creates and sends a random challenge back to the user. At this stage application displays the password entry scheme. As the user enters the password, the random challenge is encrypted by the message digest of the password. How Yahoo and Hotmail Works: With banking, anonymizer.com, or other SSL-secured web sites, they maintain the SSL session so your traffic remains encrypted. That doesn't have to be that way, however. In Yahoo Mail's case, the login page is SSL secured. Once you are done with the secured login, you no longer have an SSL session anymore. Look for the padlock icon in the status bar. It is there on the login page (if you pick the https:// URL for the login page) but it is NOT there once you are on the webmail pages. If you used the SSL login page, you get redirected to a non-SSL page after the login has been submitted. Note that SSL could still be used even when the current page is not SSL-secured, by submitting form data to a SSL-secured page. This is how Hotmail's login page works. When you login to Hotmail, you are on a Passport.net page and there is no padlock icon in the status bar (because you don't yet have an SSL session). When you click the Sign In button, the action="https://login.passport.com/ppsecure/post.srf clause for the <form> tag directs the data for the form with your login credentials gets sent to the HTTPS page. So you aren't SSL secure for the login page but the credentials are submitted to an SSL-secured page (i.e., from the non-SSL page rendered locally in your browser, you enter the data and click Submit, your browser connects to the HTTPS site for an SSL session, and then the credentials are sent encrypted
to that other page). There is no HTML for Yahoo Mail's Compose web page that would submit form data to an SSL-secured page or site, so the absence of the padlock icon in the browser's status bar means you are NOT on a secure page when composing and sending your message. Your login can be secured but your message contents are not. Personally we feel the padlock icon should be there to know if SSL is still in use. That gives a visual clue as to your security. Submitting form data from a non-secure page (rendered locally) which then has it sent to an SSL secured page or site means you don't know if the transmit is secure unless you look at the HTML code. Submitting form data to an SSL page is cheaper than allocating SSL resources up front and pending them until you complete the login, but that leaves you in the dark as to how secure are your login credentials. Bank always establishes an SSL session and persists so that the padlock icon is present during my session. They do that deliberately to let you know you have a secure connection. Yahoo doesn't need to do that, even when using their web mail interface, since they are only securing your login, not your message content. Same for Hotmail. If you don't see the padlock icon showing you have a current SSL session, you'll have to check the HTML code to verify form data gets submitted to an https:// page. MD5 uses the SMTP commands in the session between the e-mail client and the SMTP server (i.e., Javascript is not used). Yahoo Mail did it for the freebie accounts that do not provide POP3/SMTP servers. From Pidgorny's posts and some Googling, yep, it seems Javascript get sent from the server to handle the MD5 processing, but hopefully the server on each login sends a different randomized key. You can see the MD5 parameters in the URL that Yahoo sends to you when using MD5 (if you log the HTTP session). That's why we are not sure Yahoo POPs bothers to run the Javascript that gets sent by the server for the MD5 secured login. Normally the key sent by the server was a parameter in the URL returned to the client (Yahoo Pops). Mostly MD5 also only encrypted the password and not the username whereas SSL encrypts both; however, the username is included in outbound e-mails, anyway, and since that is plain text than any sniffer could get the username. Outside an organization that is geographically distributed, especially across a WAN, where IPSec makes sense, We haven't been able to find out any public sites across the Internet that provides IPsec support. Most end users have trouble figuring out how to configure the e-mail client for non-SSL (i.e., standard) connections, some may use an SSL connect, if available, and few even bother with x.509 or PGP certificates for digital signing or encryption, so I doubt IPsec is something that gets embraced for services to the typical nondescript user community. IPsec seems mostly used for same-LAN host-to-host connection (client/server and peer-to-peer), WAN connects between routers and gateways, and for dial-up clients and Internet access from private networks IPSec havent been used for any e-mail or web mail services. Wouldn't IPsec actually require access to the hardware or hosts on which IPsec was enabled (so you can load the driver and manage the policies)? Well, banks and other secured sites are often hosted by contracted web host providers so the client never has access to the hosts to modify their networking configuration and policies. A bank doesn't want to redesign their web page or manage the web hosting provider's networking should they switch to a different web-hosting provider. Using security at the application level, like SSL, means the client who ultimately provides the services of that site retains control over security. The web-hosting provider obviously isn't going to let their customers monkey around with their network configuration and policies and let customers mangle their IPsec setup. Gmail:
Unlike many other Web-based email providers, Gmail offers an SSL-encrypted login by default. This means that your Gmail password is always encrypted when it is sent over the Internet. Secure HTTPS access is also available by going to https://gmail.google.com directly. This is just another way that Gmail ensures your privacy and security! A typical login session for most users goes something like this... We type http://gmail.google.com into the Location Bar of our favorite web browser. We are then taken to an SSL encrypted page where we can put in our login credentials. Some email services only encrypt part of the page, but Gmail does the whole thing. No matter, the effect is the same. When we click the Sign In (Login, Logon, BeamMeUP) button, our credentials are wrapped in encrypted garbage and verified against the authentication service. If all is well, we are dumped into a non-encrypted page that gives us access to our email. Feature present in Gmail, hotmail and yahoo mail are describe as under Gmail Padlock SSL (Login Page) MD5 https Yes Yes Yes Yes Hotmail No Yes Yes Yes Yahoo mail No Yes Yes Yes
An Insight into Cookie Security

A web server can store data on your computer and retrieve it later using a token called a "cookie". This feature is controversial because it can both provide nice features while web browsing and can be used to invade your privacy and even compromise your computer. Cookies are often used to capture data about your online behaviour, and only sometimes for personalizing a site according to your preferences. Cookies can also be placed by and later used by installer programs, viruses and Trojans. Cookies do not act maliciously on computer systems. They are merely text files that can be deleted at any time - they are not plug ins nor are they programs. Cookies cannot be used to spread viruses and they cannot access your hard drive. This does not mean that cookies are not relevant to a user's privacy and anonymity on the Internet. Cookies cannot read your hard drive to find out information about you; however, any personal information that you give to a Web site, including credit card information, will most likely be stored in a cookie unless you have turned off the cookie feature in your browser. In only this way are cookies a threat to privacy. The cookie will only contain information that you freely provide to a Web site.
Today most websites and web based applications use cookies. Web sites use cookies for several different reasons:
To collect demographic information about who is visiting the Web site. Sites often use this information to track how often visitors come to the site and how long they remain on the site. To personalize the user's experience on the Web site. Cookies can help store personal information about you so that when you return to the site you have a more personalized experience. If you have ever returned to a site and have seen your name mysteriously appear on the screen, it is because on a previous visit you gave your name to the site and it was stored in a cookie so that when you returned you would be greeted with a personal message. A good example of this is the way some online shopping sites will make recommendations to you based on previous purchases. The server keeps track of what you purchase and what items you search for and stores that information in cookies. To monitor advertisements. Web sites will often use cookies to keep track of what ads it lets you see and how often you see ads.
Introducing Cookie Managers
The web browser can either store the cookies in its memory or the hard disk depending on whether the cookie is persistent or non persistent.
Persistent cookies remain stored on the hard drive even after a user has logged out of the application. The persistent cookies are generally stored in a file. Non Persistent Cookies or Session Cookies get created and stored temporarily in the memory and is destroyed at the end of the users session.
The browsers also come with a tool called cookie managers to efficiently view and manage the cookies.
Cookie Composition
A cookie is composed of a number of attributes. To understand the structure of a cookie we now take a look at a popular email service. Heres a snippet of the cookie which is sent by Gmail when a user logs in, SetCookie: GV=; Domain=mail.google.com; Expires=Sun, 09Oct05 13:47:42 GMT; Path=/mail
Cookies have six parameters that can be passed to them:
The name of the cookie. The value of the cookie. The expiration date of the cookie - this determines how long the cookie will remain active in your browser. The path the cookie is valid for - this sets the URL path the cookie us valid in. Web pages outside of that path cannot use the cookie. The domain the cookie is valid for - this takes the path parameter one step further. This makes the cookie accessible to pages on any of the servers when a site uses multiple servers in a domain. The need for a secure connection - this indicates that the cookie can only be used under a secure server condition, such as a site using SSL.
In the example above, GV is the name of the cookie, which is valid for all URLs under /mail at the domain mail.google.com.
Security Risks
Incorrect Domain Settings
The cookie which we took as example was a valid cookie that worked only for its current domain. However if a web designer accidentally sets the domain field of a cookie to a value of .com or .edu it would mean that the cookie will become valid for a large chunk of the Web which had websites ending in .com or .edu. This is the reason all cookies that have .com or .edu or .net are disabled by default as per the RFC 2965 which speaks about HTTP state management.
Incorrect Path Settings The PATH field in a cookie controls the directories on the server the cookie is valid for. In the earlier example we saw a cookie GV which had the PATH field set to /mail. This implies that if a user had this cookie it would be valid for all directories under /mail only. There would be other mechanisms to prevent him from viewing other users mailboxes under /mail. However if this cookie is incorrectly set to / instead of a specific directory, then the cookie may become valid for all directories. A malicious user may be able to manipulate the URL and view the root directory of the mail server. This could potentially result in a lot of sensitive information being leaked to unauthorized users.
Login using Persistent Cookies At times websites use a persistent cookie to authenticate a user. If we take Gmail as an example and check the Remember me on this computer box before logging in Next time Gmail is opened the user will be directly logged in without providing username and password. The rememberme cookie has a namevalue pair which contains text > Expires: 04/17/2016 05:52:10 PM Since the expires attribute is set to a future date a persistent cookie is set by Gmail. The next time a user visits Gmail, if the rememberme cookie has not expired it'll take him directly to the Inbox. Use of persistent cookies for authentication can be a big risk in a shared environment like a cyber caf.
Sensitive Information in Persistent Cookies There's another way in which persistent cookies can give out sensitive data. There could be a scenario where a person buys something from an online shopping website. Now when he submits his payment information online, the site may store his sensitive information such as credit card number offline in a persistent cookie. If the computer is
a shared resource another user may be able to access the cookie, obtain the credit card number and use it for malicious purpose. Ideally, it is best to avoid accessing sensitive data in a shared environment.
Caching of Cookies in Caching Proxy Server At times a caching proxy server is used which stores the web pages, images etc in its cache, so that the next time the user visits the same page it pulls the page from the cache instead of sending the request to the web server. This saves the user time and reduces load on web server. Whether the page will get cached is controlled by a set of http headers such as cache control, pragma etc. Though caching proxy servers may improve performance, it may cause a security threat if cookies are also cached. If cookies are cached on a caching proxy server then it could be stolen and used for malicious access.
Cross Site Scripting Attack Cross Site Scripting is a popular attack which is often used to steal the valid session cookie of a user using a malicious script. These scripts on executing grab the user's cookie from his machine and send it to the attacker who can then use it for malicious purposes.
Conclusion
Through the course of this paper we have seen how cookies work and how they can help you make your life easier. However we also saw that accepting cookies does expose you to certain risks and adequate protection must be taken to prevent yourself from falling victim to a hackers tricks.
Product on Firewall
Introduction
As Building Internet Firewalls says, once you've gotten used to the Internet, "you're bound to notice that not only does it let you travel, it lets a very large number of strangers show up where you are, and not all of them are people you would have invited." Firewalls are useful if one wants to protect:

Personal data Computers resources Our reputation Our liability
When discussing firewalls, people tend to focus on either the secrecy or the protection from attacks over the Internet. This is unfortunate because it encourages people to disregard security in the belief that it's only needed for 'spies' or other people who would naturally be under attack over the Internet. The truth is that everyone should be concerned about security. Consequences have readily calculable costs: if an individual loses data, he or she have to pay to have it reconstructed; if our computer is compromised and used to attack other computers, then we would have to handle the legal issues that arise.
What is a firewall?
A firewall is a 'choke-point'; a way of forcing packets to pass through the firewall in order to 'filter out' undesirable network packets:
Works by filtering out (and logging) packets sent to ports that have not been designated as "ok"
Alerts you to unusual packets Usually, only the source IP address, destination IP address, source port and destination port are examined by the firewall (this is known as packet filtering) Firewalls generally do not look at the look at the contents of a packet
Note that there are other types of firewalls, such as proxies or application layer firewalls, but the basic concept of a 'choke-point' remains the same. A firewall is only one part of a complete security stance, and does not provide complete protection. Some examples of things that firewall can not protect you from:

Attacks against specific services you're running (such as a web server) Denial of service attacks Virus infection Harassment over mediums such as email and IRC Impersonation Imperfect firewall configuration Security problems in the firewall itself
What makes a good firewall?

Good firewalls have the following characteristics:
Provide a highly detailed plain text log in a fully documented format easily read by humans (rather than being designed to be parsed by computers) Provide an abundance of informative documentation and help files
Refrain from exaggerating the potential of a threat or claiming that any incoming packet is an attack; some low-end firewalls behave this way and it makes it harder to interpret an incident Have a minimum number of false alarms Have an active user community that can help you with initial configuration, incident interpretation, and long-term maintenance Ideally, are run of a separate computer with 2 network cards and proxy the network connection to the other computers
Once again, the most important aspect of any firewall is to understand the underlying concepts and knowing how to identify problems out of the "noise lists.
Product Review
The Two products which our group has considered for this assignment
1. Secpath100F From Huawei 2. XSR Series of Firewall- From Enterasys
1. Secpath 100F- Huawei General Overview
1. The Secpath 100F series is one of the most versatile pair of security appliances available. 2. They can easily integrate and secure many different network environments, including large and medium enterprise-business sites, data centers and carrier infrastructure. 3. The secpath100F security system integrates firewall, Dos, DDos, vpn and traffic management functionality, support abundant virus defense and content filter technologies. 4. In addition, the secpath100F-NE not only support firewall features, but also can provide powerful vpn funcition, the 3DES performance can reach100Mbps, support 300,000 concurrent connections. Secpath 100F Product Overview
Robust firewall
1. SecPath 100F firewall adopts the ASPF state inspection technology to monitor the connection process and malicious commands and filter dynamic packets together with ACL. 2. Supports external attack defense, internal network security, traffic monitoring, Web filtering, and mail filtering to guarantee network security. Encryption & Authentication
1. SecPath 100Fseries can encrypt data using 56-bit Data Encryption Standard (DES), 168-bit Triple DES (3DES), or up to 256-bit Advanced Encryption Standard (AES).
2. SecPath also support ARC4; as to authentication algorithms, SecPath 100F supports MD5 and SHA-1; also SecPath 100F support pre-shared key, PKI /X.509-based key and RSA secureID key in IKE. Scalability
1. There is a MIM (Multifunction Interface Module) slot in SecPath 100F, and 1/2FE, HDC (Hard Disk Card) or NDEC (Network Encryption Card) can be applied in this slot, when FE is applied in this slot. 2. SecPath 100F can support DMZ (De-Military Zone); when HDC is applied in this slot, logs can be stored in the hard disk. VPN Technology
1. Based on the versatile software platform, SecPath security system can support following VPN technologies: L2TP, GRE, IPSEC, SSL, and particular Dynamic VPN (Huawei patent technology. 2. With these VPN technologies, customers can easily build safe VPN under any network condition. Security management
1. Real-time log on attacks 2. Blacklist log
3. Address binding log 4. Traffic alarm log 5. Session log 6. Binary format log 7. Traffic statistics and analysis 8. Global/Security domain connection number based monitor 9. Global/Security-domain monitor of protocol packet proportion 10. Security event statistics 11. E-MAIL real-time alarm 12. Scheduled release of E-MAIL information
Deployment Scenario (2 Views)
2. Product Review Two XSR 3000 Series Enterasys
1. The XSR 3000 Series Security Router/Firewall delivers simple and powerful enterprise WAN networking by combining comprehensive IP routing features; a broad range of WAN interfaces; and a rich suite of security functions, including siteto-site and remote access Virtual Private Networking and policy-managed, stateful-inspection firewallin a single device. 2. The addition of an enterprise-class firewall complements the XSRs industry-leading IP WAN routing, Quality of Service, NAT functionality and VPN features, making it ideally suited to
remote offices that require connectivity, VPN and firewall functionality. 3. And, unlike typical security appliances, the XSR provides extensive IP routing, Quality of Service (QoS) and a wide range of WAN interfaces.
Technical Specifications
1. The Enterasys XSR Firewall incorporates the key characteristics of standalone firewall appliancesincluding filtering packets at the network layer, determining the legitimacy of IP sessions and evaluating the payload of packets at the application layer. 2. The XSR Firewall delivers industry-leading price-performance ratios and so much more. 3. The XSR Firewall allows a direct connection between client and host, alleviating the lack of transparency of Application Level Gateways (ALGs). It also employs algorithms to recognize and process Layer 5-7 data. Additional stateful-inspection firewall advantages include:
Inspection of a packets communication and application state, acquired from past communication data throughout all layers. For example, an FTP sessions PORT command can be saved to verify an incoming FTP data connection. Dynamic filtering by opening ports only if the configured policy permits and when the application requires. An Application Layer Gateway (ALG) to support applications that dynamically allocate ports for secondary data streams. ALGs apply stateful inspection to complex protocols such as FTP and TFTP, H.323, RPC, DHCP Relay, GRE for NAT, etc. Smart service filtering and blocking. For example blocking unauthorized commands to an e-mail server, avoiding possible attacks.
Intelligent Denial of Service prevention: Ping of Death, TCP Port Scan, ICPM and UDP Flood, session hijacking, and more. The capacity to search for and reject non-forming packets.
Difficulties encountered while installing a Firewall.
1. One of the difficulties of firewall implementation is the fairly high degree of technical expertise required to configure them 2. If one does not understand TCP/IP reasonably well there is little hope of properly setting up a packet filtering Facility. 3. Exactly how much technical knowledge is needed depends on the product installed. 4. Almost without exception no matter how mature and well written the software is there are myriad of administrative tasks in setting up a firewall. 5. The multiple protocols not just TCP/IP are the norm on extranet and intranet networks. 6. Most firewalls today are created to operate only on the TCP/IP environment.
7. To protect only one protocol that is IP is ludicrous, in a standard corporate network environment while the norm is to deploy 3 and 18 protocol suites to satisfy legacy and computational requirements. 8. Popular operating Systems such as Windows NT/2000 come configurable with multiple protocols to satisfy corporate clients. 9. Proper firewall requires all entities to receive equal protective treatment to truly address the network security threat. 10. Even with a fairly effective firewalls for internet access there are situations that are left unchecked, will cause defeat of firewalls. For example end to end encapsulation where a tunneling protocol tunnels under itself is very hard to detect.

Student Assignments

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Student Assignments

Încărcat de

Drepturi de autor:

Formate disponibile

ASSIGNMENT ON:Create a digital certificate & install it using java key tool.

Step 5: Select Computer Account.

Step 6: Close the snap-in panel, clicking OK

Getting a Thawte test SSL certificate

Setting up a secure website using HTTPS in Orion

Step 3: Make Login Page.

Code of Login Page (index.jsp)

General SSL debugging

Security Management Assignment E-Mail Security

Examples of email security issues include the following:

IP addresses of Gmail users are disguised in order to protect security [17].

Web-Based Mail Access

Yahoo Mail And Hot Mail

15.0.1 15.0.2 Inaccurate identification

15.0.3 Cookie poisoning

15.0.4 Cross-site cooking

15.0.5 Inconsistent state on client and server

Study of Ethical Hacking Tools

15.0.6 What is ethical hacking?

15.0.8 Remote Console

15.1 Service and Version Detection

An Insight into Cookie Security

Introducing Cookie Managers

Incorrect Domain Settings

Personal data Computers resources Our reputation Our liability

What makes a good firewall?

1. Secpath100F From Huawei 2. XSR Series of Firewall- From Enterasys

1. Secpath 100F- Huawei General Overview

1. Real-time log on attacks 2. Blacklist log

Deployment Scenario (2 Views)

2. Product Review Two XSR 3000 Series Enterasys

Difficulties encountered while installing a Firewall.

S-ar putea să vă placă și