http://www.travelauto.com/ Website review
Send a request:(become a member)
http://www.travelauto.com/corporate/partners/service-provider/become-a-member.html
accepting data without validating the content. Validating only mandatory.
Showing always email already existing error validation
Service provider already exist error
Get a Quote:
http://www.travelauto.com/quotes.html
accepting data without validating the content. Validating only mandatory.
Contact Us
http://www.travelauto.com/contact-us.html
Only validating mandatory fields.
No validations for content, phone number, email. All fields accepting data containing special
charactors,symbols, digits
New User signup
http://www.travelauto.com/registration.html
Only validating mandatory fields
1 Login Issues
Password should n't be clear text. saving pwds in cleartext in a database is not good.
Redirecting to a newpage after login will prevent the attackers to login to the same application otherwise if
it is single file once the valid user logged out attackers will use back button and resubmit the values to the
same page to login to the application.
Forgot password feature putting a security question will give a chance to attacker to guess the answer to
login with new password. like this forgot pwd feature may be exploited.
it is always better to force the users reset their passwords when they forget their passwords rather than
displayed it on the mails because displaying the password means it has to be stored in a recoverable form
in the database. Passwords are best stored as non-recoverable hashes in the database
Secure way to design the Forgot Password feature
Asking the user to supply some details like personal details or ask a hint question. Then we should send a
mail to the users authorized mail id with a link which will take the user to a page for resetting the password.
This link should be active for only a short time, and should be SSL- enabled.
Precautions to protect the site while using from publicly shared computers
You can make sure your pages do not get cached on the system by setting the correct cache control
directives.
You could take care that no sensitive information is included in the URLs since the history of the client
browser will store these.
Have a graphical keyboard for entering the password or ask the user to enter a different part of the
password each time. This protects the password against keystroke loggers.
To prevent sniffing of passwords and replay attacks using those, you should either use SSL or salted MD5
for passwords. The clear text password in the memory should be reset after computing the MD5
2.SQL Injection
SQL Injection is a technique by which attackers can execute SQL statements of their choice on the backend
database by manipulating the input to the application
Preventing SQL Injection in an Application
It is quite simple to prevent SQL injection while developing the application. You need to check all
input coming from the client before building a SQL query. The best method is to remove all unwanted input
and accept only expected input. While server side input validation is the most effective method of
preventing SQL Injection, the other method of prevention is not using dynamic SQL queries. This can be
achieved by using stored procedures or bind variables in databases that support these features. For
applications written in ASP applications, ADO Command Objects can be used.
Using stored procedures can prevent SQL Injection because the user input is no longer used to build the
query dynamically. Since a stored procedure is a group of precompiled SQL statements and the procedure
accepts input as parameters, a dynamic query is avoided.
3.Variable Manipulation
For manipulating any information, including form fields, hidden variables and cookies, attackers use tools
known as HTTP/HTTPS proxy tools. Once the browser's proxy settings are configured to go through the
HTTP/HTTPS proxy, the tool can see all information flowing between the client and the server; it even
allows the attacker to modify any part of the request before sending it. Some such tools are: WebScarab
can be used
Preventing variable manipulation
The main threat these proxy tools pose is editing the information sent from the client to the server. One
way to prevent it is to sign the message sent from the client with a Java Applet downloaded onto the client
machine. Since the applet we developed will be the one validating the certificate and not the browser, a
proxy tool will not be able to get in between the client and the server with a fake certificate.
4.Browser Cache
The browser has a capability to temporarily store some of the pages browsed. These cached files are stored
in a folder, like the Temporary Internet Files folder in the case of Internet Explorer. When we ask for these
pages again, the browser displays them from its cache. suppose the attackers access the same machine and
searches through the Temporary Internet Files, they will get the credit card details. The attackers do not need to
know the username and password of the user to steal the information.
Preventing browser cache
The response header sent from the server has some cache control directives that can be set from your code.
These directives control the caching of content on any cache. The directives to be set are Cache-Control :
no-cache, no-store and Expires: 0. But since legacy HTTP 1.0 servers do not support the Cache-Control
headers, universally, Pragma: no-cache header should be used, too.
5. Cross Site Scripting
Cross Site scripting (XSS) is a type of attack that can be carried out to steal sensitive information belonging
to the users of a web site. This can be used to steal cookies and session Ids.
The attackers can send a link that contains a script as part of the URL to a user. When the user clicks it, the
script gets executed on the user's browser. This script may have been written to collect important
information about the user and send it to the attacker
Preventing XSS:
XSS can be prevented while coding the application. You should be validating all input and output to and
from the application and escape all special characters that may be used in a script.
If the code replaces the special characters by the following before displaying the output, XSS can be prevented to
some extent.
<<
>>
( &*40;
) &*41;
&*35;
& &*38;
6.Cryptography/SSL
Secure Socket Layer (SSL) gives us assurance of two things. Firstly when a client connects to a web server,
the client can be sure that it is talking to the right server by checking the certificate the server sends it.
Secondly, SSL assures you of the confidentiality of the data, as the client and the server exchange encrypted
messages that cannot be understood by anybody else. This is how SSL works
II) How to Audit ASP.NET Applications for PCI DSS Compliance
Application security remains one of the key factors in avoiding a security breach. PCI DSS (Payment Card
Industry Data Security Standard) recognizes this and specific requirements have been outlined to ensure
that companies have processes in place to ensure that applications are developed, deployed, and
maintainance.
OWASP Top 10 was the only recommendation. As such, it has been widely adopted by companies and
vulnerability
management products and it has become the default standard for web application security.
The main difference between OWASP Top 10 and CWE/SANS Top 25 is that OWASP Top 10 covers general
concepts and is focused exclusively on web applications while CWE/SANS Top 25 covers specific software
errors and could be applied to any type of software applications.
PCI DSS Requirements that Apply to Web Based Applications
1. Architechture Audit
2. Design Audit
3. Secure Coding
Requirement
Category
1.3.7 Place system components that store cardholder data (such as a database) in an internal
Architecture Audit
network zone, segregated from the DMZ and other untrusted networks.
2.2.1 Implement only one primary function per server to prevent functions that require different
security levels from co-existing on the same server. (For example, web servers, database
Architecture Audit
servers, and DNS should be implemented on separate servers.)
3.2 Do not store sensitive authentication data after authorization (even if encrypted).
Sensitive authentication data includes the data as cited in the following Requirements 3.2.1
Design Audit
through 3.2.3:
3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of
Design Audit
digits to be displayed).
3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup
Design Audit
media, and in logs) by using any of the following approaches:
One-way hashes based on strong cryptography (hash must be of the entire PAN)
Truncation (hashing cannot be used to replace the truncated segment of PAN)
Index tokens and pads (pads must be securely stored)
Strong cryptography with associated key-management processes and procedures
3.5 Protect any keys used to secure cardholder data against disclosure and misuse:
Note: This requirement also applies to key-encrypting keys used to protect data- encrypting
Architecture Audit
keys—such key-encrypting keys must be at least as strong as the data-encrypting key.
4.1 Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.)
Design Audit
to safeguard sensitive cardholder data during transmission over open, public networks.
Examples of open, public networks that are in scope of the PCI DSS include but are not limited
to:
The Internet
Wireless technologies,
Global System for Mobile communications (GSM)
General Packet Radio Service (GPRS).
6.3 Develop software applications (internal and external, and including web- based
administrative access to applications) in accordance with PCI DSS (for example, secure
authentication and logging), and based on industry best practices. Incorporate information
security throughout the software development life cycle. These processes must include the
Secure Coding
following:
Requirements from 6.3.1 thru 6.3.2
6.5 Develop applications based on secure coding guidelines. Prevent common coding
Secure Coding
Requirement
Category
vulnerabilities in software development processes, to include the following:
Note: The vulnerabilities listed at 6.5.1 through 6.5.9 were current with industry best practices
when this version of PCI DSS was published. However, as industry best practices for
vulnerability management are updated (for example, the OWASP Guide, CWE/SANS Top 25,
CERT Secure Coding, etc.), the current best practices must be used for these requirements.
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing
basis and ensure these applications are protected against known attacks by either of the
Secure Coding
following methods:
Reviewing public-facing web applications via manual or automated application
vulnerability security assessment tools or methods, at least annually and after any
changes
Installing a web-application firewall in front of public-facing web applications
7.1 Limit access to system components and cardholder data to only those individuals whose
Design Audit
job requires such access. Access limitations must include the following:
Requirements from 7.1.1 thru 7.1.4
7.2 Establish an access control system for systems components with multiple users that
restricts access based on a user’s need to know, and is set to “deny all” unless specifically
Design Audit
allowed.
This access control system must include the following:
Requirements from 7.2.1 thru 7.2.3
8.4 Render all passwords unreadable during transmission and storage on all system
Design Audit
components using strong cryptography.
8.5 Ensure proper user identification and authentication management for non- consumer users
Design Audit
and administrators on all system components as follows:
PCI DSS Requirements from 8.5.1 thru 8.5.16
10.1 Establish a process for linking all access to system components (especially access done
Design Audit
with administrative privileges such as root) to each individual user.
10.2 Implement automated audit trails for all system components to reconstruct the following
Design Audit
events:
Requirements from 10.2.1 thru 10.2.7
10.3 Record at least the following audit trail entries for all system components for each event:
Requirements from 10.3.1 thru 10.3.6
Design Audit