BUDDHA INSTITUTE OF TECHNOLOGY

Department of Computer Science & Engineering

Diploma in Engineering
A Repot on:
[ Basic of web development ]

Name:
Board Roll: 4117418230
Semester: 4th
Batch: 2023-26
Session: 2024-25
 Secure Web development

ABSTRACT
This chapter is an effort to develop secure web applications based on known
vulnerabilities. It has been seen that in the rapid race of developing web
applications in minimum time and budget, security is given least importance
as consequence of which web applications are developed and hosted with
number of vulnerabilities in them. And in this race, one thing is constant that
attackers take advantage of weaknesses existing in technology for financial
gain and theft of intellectual property. In this proposed method of secure
web development, most common vulnerabilities and their occurrence in
development process is discussed. Mapping vulnerabilities to the actions
needed to take during development process may help developers to
understand vulnerability and avoid vulnerabilities in application.

INTRODUCTION
Since the development of internet, web applications have become very
popular, and, nowadays, they are used in every environment, such as
medical, financial, military systems. But in the race to develop these online
services, web applications have been developed and deployed with minimal
attention given to security risks, resulting in surprising number of corporate
sites that are vulnerable to hackers (Halkidis, 2008). With the rise in web
applications for security critical environment, number of attacks against
these applications has grown as well. Organizations face more security risks
imposed upon them by hackers on achieving fame, glory, profit or
information. Malicious hackers are finding out constructively new ways to
exploit web applications. According to study conducted by Imperva’s
Application Defense Center (ADC), web sites experience an average of 27
attacks per hour or about every two minutes (Be’ery et al, 2011). When sites
come under automated attack, the target can experience up to 25,000
attacks per hour or 7 per second (Be’ery et al, 2011). The number of daily
web based attacks observed was 93% higher in 2010 as compare to 2009,
according to report by Symantec on attack Kits and malicious websites
[SYM].

Web based attacks are rising consistently and there are number of reasons
that make applications so vulnerable. The rise in attack volume in web
applications is due to ready availability of attack toolkits, many of which
exploit known vulnerabilities (Malek, 2004). Hacking tools and guides are
available on-line, almost anyone can launch attack using these resources.
Web applications have become interesting target for many for achieving
fame, profit or information. Hackers continue to focus on web applications
because these are easy points of entry and valuable data is exchanged in
business processes run by these web applications. Developers are mandated
to deliver functionality on time and on budget but not to develop secure
applications. Developers are not generally educated in secure code
practices. According to CERT/CC, more than 90% of vulnerabilities leak out
during development. They are result of ignoring known vulnerabilities
found in other
 2

systems (Nany and Gary, 2005). Keeping this fact in mind, this chapter is an
attempt that will help to develop partially secure web applications avoiding
vulnerabilities.
The chapter describes related work, the development life cycle, most
common vulnerabilities in web applications and then explains the actions
proposed to avoid vulnerabilities. In the end, mapping of vulnerability to
action is done to understand and avoid the vulnerabilities and future scope is
discussed.

RELATED WORK

There are existing processes, standards, life cycle models, frameworks, and
methodologies that support or could support secure software development.
Security Development Lifecycle (SDL), which focuses on producing secure
software, is a software assurance methodology and tool that aims at
assisting software developers, designers, builders, and educators in
improving the security of software production. SDL prescribes activities to
embed security into applications and supplies the foundation for a broad
software security assurance that extends across an IT enterprise [FOR],
(Hajar and Salman, 2011). The SDL introduces security and privacy
throughout all phases of the development process. SDL includes five
phases: Training, policy, and organizational capabilities, Requirements and
design, Implementation, Verification, and Release and response. It includes
mandatory security activities executed as part of a software development
process.

The Requirements phase of the SDL includes consideration of security and

privacy at a foundational level. The best opportunity to build trusted
software is during the initial planning stages, when development teams can
identify key objects and integrate security and privacy [MSD]. The Design
phase includes building the plan for implementation, release, and functional
and design specifications, and performing risk analysis to identify threats
and vulnerabilities. Functional specifications may describe security and
privacy features directly exposed to users, such as requiring user
authentication to access specific data or user consent before use of a high-
risk privacy feature. Design specifications describe how to implement these
features and how to implement all functionality as secure features [MSD]. An
extra security activity includes a final code review of new as well as legacy
code during the Verification phase. Finally, during the release phase, a Final
Security Review is conducted by the Central Microsoft Security team, a team
of security experts who are also available to the product development team
throughout the development life cycle, and who have a defined role in the
overall process (Steve and Howard, 2005).

Microsoft Trustworthy Computing Software Development Lifecycle, the Team

Software Process for Secure Software Development (TSP-Secure),
Correctness by Construction, Agile Methods, etc. are process models for
secure software development (Davis, 2005). Also, it is important to
understand the processes that an organization is using to build secure
software, because unless the process is understood, its weaknesses and
 3

strengths are difficult to determine.

DEVELOPMENT LIFE CYCLE

 4

The development of the web application goes through different phases:

Requirement, Design, Coding, Testing and Deployment. Secure web
application can be developed only by securing all these phases of
development life cycle. Ignoring security at any of these phases can result in
insecure web application. Moreover, flaws that experts discover at the
deployment level of web application are expensive and time-consuming to fix
[IBM]. As table 1 shows that fixing a design error in deployment phase is 30
times more costly than fixing it in design phase.

Error Corrected Corrected Corrected Corrected Corrected

Found in in Design in Coding in in Beta in
phase integration Testing Deploymen
Testing t
Design 1X 5X 10X 15X 30X

Coding 1X 10X 20X 30X

Integration 1X 10X 20X

Table 1: Cost of Fixing Error

Error in early phase persists in later phases and later in the

application too (Bar-Gad and Klein, 2002). For this reason, a flaw should be
discovered and removed at the earliest. Figure 1 illustrates a development
life cycle based on known vulnerabilities and agile development. Also, this
model assumes that developers, project manager and everyone associated
with product development are aware of security and their common breaches.

Figure 1: Development Life cycle with security

The basic idea of this model is develop product in increments i.e., develop a
small sub- product with few requirements and then in next iteration, develop
another sub-product and integrate with existing one. Keep on repeating the
iterations until the final complete product is not ready. Also one important
thing is that security is inculcated in each phase of development life cycle.

COMMON VULNERABILITIES
Vulnerability is a hole or weakness in application, which can be design flaw
or implementation bug that allows an attacker to cause harm to stakeholders
of an application (Chunguang et. al, 2006). Almost 80% of web application
attacks are from known vulnerabilities (Raviv, 2012). This is shown in figure
2. This section introduces 20
 5

common vulnerabilities and also includes the general description, creation

phase of development life cycle. For reference, these vulnerabilities are
assigned a code.

Figure 2: Different web application attacks

WV 1- SQL Injection: SQL injection is a very old approach but it's still popular
among attackers. This technique allows an attacker to retrieve crucial
information from a Web server's database. Constructing a dynamic SQL
statement (constructing SQL queries by string concatenation) with user input
may allow an attacker to modify original statement to illegal SQL statement.
The cause of this vulnerability is weak input validation and can be avoided by
allowing only alphanumeric characters, especially avoid double quote (”),
single quote (‘), semicolon (;), colon (:) and dash(-) . Most SQL injection
vulnerabilities can be easily fixed by avoiding use of dynamically constructed
SQL queries and using parameterized queries or stored procedures instead
[WVR], (Uzi Ben-Artzi and Donald, 2003).

WV 2- Cross site scripting (XSS): XSS is a kind of injection vulnerabilities,

attacker injects malicious tags and /or script code that is executed by user’s
web browser when accessing the vulnerable website. The injected code takes
the benefit of trust given by user to vulnerable site These attacks are
targeted to all users of web application instead of web application itself
[Impact2009]. Every technology or language like ASP, PHP, CGI, Perl,
Asp.NET, JSP, VB.NET and C# may face this vulnerability (Shirazi, 2009). The
results of these XSS attacks range from revealing authentication credentials
to feeding sensitive information to a remote user or host, propagating the
attack to other members or administrators of the site, and creating Man-in-
the-Middle attacks such as Phishing attacks. Data validation, data cleansing,
disabling scripting languages, limiting cookie access and not saving sensitive
data in the cookies reduce the risk of XSS (Micha, 2009).

WV 3- Invoking untrusted mobile code/Malicious file Execution: Malicious File

execution flaw could allow attackers the opportunity to include hostile code
and data, resulting in devastating attacks, such as total compromise of the
server. Uploading and executing code from external sources causes this
vulnerability. Malicious file attack can an affect PHP, XML and any framework
that accepts filenames or files from users [OWA]. In case of using such files,
demand adequate certificates to ensure safety (Michal et al, 2009).

WV 4- Weak Cryptography and insecure cryptography storage: Poorly protected

data may be used by attackers to steal identity, credit card information or to
conduct other crimes. Web applications must properly protect sensitive data
such as credit cards, Social Security numbers (SSN) and authentication
credential with suitable encryption or hashing
. Countermeasure to this flaw is to make proper use of cryptographic
 6

functions to protect data and credentials [OWA]. At coding level, avoid hard
coding of data.
 7

WV 5 -Information Leakage: Applications can unintentionally leak information

about their configuration, internal workings, or violate privacy through a
variety of application problems [OWA]. Attackers can use this weakness to
steal sensitive data, or conduct more serious attacks. Error messages should
be checked for unnecessary or extra information. Data must be encrypted is
another consideration (Jay and John, 2004).

WV 6- Broken Authentication and Session Management: Broken access and

session is due to authentication and authorization flaws. Applications built
using custom authentication and session management schemes may have
flaws in the areas such as logout, password management, timeouts,
remember me, secret question, account update. Such flaws may allow
accounts to be attacked and compromise passwords, keys, session tokens, or
exploit implementation flaws to assume users’ identities [OWA], (Metula,
2012). This flaw is caused when account credentials and session tokens are
not protected properly.

WV 7- Cross site Scripting Forgery(CSRF): A CSRF attack creates forged HTTP

requests and tricks a victim into submitting them via image tags, XSS, or
other techniques. If the user is authenticated, the attacker succeeds [OWA].
As browsers send credentials like session cookies automatically, attackers
can create malicious web pages which generate forged requests that are
indistinguishable from the legitimate ones. Forcing users to log off and
checking referrer headers can help but for complete solution include
authentication tokens in the body of every request (Walker, 2012).

WV 8- Format string: This vulnerability occurs when the user is able to control
format string used in printf style functions. This attack alters the flow of
application by using string formatting library features to access other
memory space [WAS]. Attackers can set buffer overflow attack taking control
over format string. To avoid this, user input should not be passed to
formatting functions directly (Shirazi, 2009). Formatting functions should
accept only static string as input.

WV 9-Security mis-configuration: A secure web application requires a strong

server configuration. A poorly configured server can potentially create
multiple security vulnerabilities. A default server may have many features
turned on for convenience and may have software packages that are pre-
installed and should be removed. Operating a server with a default software
setup and configuration may cause multiple security vulnerabilities that may
be exploited by hackers. Server configuration is not typically the
responsibility of the programmers, and should be addressed by server and
network administrators. The host server should be assessed for security
issues, which will usually reveal what packages are installed and their
versions, missing patches and updates or upgrades, and provide a hit list for
which packages should be removed, disabled or correctly configured (Shirazi,
2009).

WV 10- Failure to restrict URL access: Failure to restrict URL access may
enable attackers to forge URLs to access hidden pages or admin pages
 8

[OWA]. Countermeasure to this vulnerability is to check URL access rights or

perform access control checks when
 9

these pages are requested. In case of violation of URL access, an error page
should be return to user.

WV 11-Invalidated Redirects and Forwards: Invalidated redirects and forwards

take place when the attacker redirects the users to malicious web pages or
phishing web sites.

WV 12-Insufficient Transport Layer Protection: Protecting network traffic for

sensitive communication is necessary as it can be stolen by attackers. Mostly
applications don’t encrypt sensitive traffic and even if they do, they use
weak algorithms, expired or invalid certificates, or do not use them correctly
[OWA].

WV 13- Brute Force: Brute force attack automates a process of trial and error
to guess a person’s user name, password, credit-card number or
cryptographic key [WAS]. In this method unknown value is determined by
using automated process to try large number of possible values. To avoid
this always select a password with minimum of 8 character alphanumeric
and do not use common words and terms as passwords.

WV 14- Content spoofing: Content spoofing is a client side attack by illegal

execution of foreign code [WAS], [WHW]. In this technique attacker can
inject malicious payload that is later misrepresented as legitimate content of
web application.

WV 15- Buffer Overflow: Buffer Overflow attack is performed by submitting

more information than a variable is expecting to receive, causing the
“overflow” of data to write over a section of memory where another process
may subsequently access and execute it. If the section of overwritten code
contains the correct executable content for the process that happens to
access it, the results could range from a defunct server or process to a
compromised server with associated exploitations. Some web applications
components in some languages do not correctly validate user-submitted
input and may crash or freeze a server. Languages like Java, C# are good
options as they are less vulnerable to buffer overflow attacks (Shirazi, 2009).
While coding, input variables should be given appropriate size to reduce this
vulnerability.

WV 16- Injection Flaws (LDAP, SSI, XPath): Injection flaw basically allows to
insert specially formulated data, code, script in order to affect normal
execution [CUS]. Mostly injection flaw attacks occur when user sends some
illegal input. LDAP (Light weight directory access Protocol) injection attack
exploit web sites by constructing LDAP statements from user supplied inputs.
XPath injection constructs queries from user supplied input. SSI (server Side
Include) sends code to web server which is then executed locally [WAS]. To
avoid injection flaws user inputs should be validated properly.

WV 17- Denial of Service (DoS): A denial-of-service attack or distributed denial-

of- service attack (DDoS attack) is an attempt to make a resource
unavailable to its intended users. DoS attackers typically target sites or
 1
0
services hosted on high-profile web servers such as banks, credit card
payment gateways etc. One common method of attack involves saturating
the target (victim) machine with external communications requests, such
that it cannot respond to legitimate traffic, or responds so slowly as to be
rendered
 1
1
effectively unavailable. Preventing DoS and DDoS attacks requires the
integration of multiple prevention techniques such as firewalls, routers,
switches. Low-volume web environments may make more use of
programming-level prevention, but DoS/DDoS prevention is more of a server
and network level approach.

WV 18- Directory Indexing and Path Traversal: Directory indexing is an

automatic listing of web server function that shows all files in requested
directory if normal base file is not present [WAS]. Path Traversal allows to
track paths used in system files (Shirazi, 2009). Best solution is to adequate
input validation.

WV19- Improper Error Handling: Many vulnerabilities occur when errors are not
handled properly. A server that is configured to operate in Debug mode may
offer considerable information about the error, which may reveal server and
application pathways, file names, code segments, server types and versions,
and other information. All of these contribute to resources the attacker will
use to exploit the web application and server. Once a poorly handled error is
discovered, an attacker may iterate man types of errors to collect a wide
range of information about the server. Some errors, especially crafted errors
by an attacker, may result in denial of service or cause the server to fail in
some form. Some security features of the web application may become
voided by some error situations, creating yet more vulnerabilities. To counter
this, errors should be handled in such a way that system preserves its secure
state (Shirazi, 2009). All the expected and unexpected errors should be
handled in a proper way and error message generated by application should
be issued only as needed void of any extra information (Younan, 2003).

WV20- Insecure Direct Object References: A direct Object reference occurs

when a reference to an internal implementation object, such as file,
directory, or database key is exposed. Applications do not always verify the
user is authorized for the target object, resulting in an insecure direct object
reference flaw [OWA]. These flaws can compromise all the data that is
referenced by the parameter.

ACTIONS TO AVOID VULNERABILITIES

Secure software engineering is an approach for secure software
development which means that security must be implemented during the
software development phases. Keeping this thing in mind, this section lists
the actions needed to take during design, coding, testing, configuring and
hosting of the web application to avoid most common vulnerabilities. For
further references, code is assigned to each action.

Act-1: Only accept input values specified in white list and if user supplies any
other input, reject it.
Act-2: When it is not possible to predict exactly type or form of input use
sanitization strategy i.e. use escaping or encoding characters so that
it will not affect back end system.
Act-3: Along with validating external boundaries, each component of
 1
2
application must validate data coming from and going to other
components.
 1
3
Act-4: Make sure that if an attacker manages to cause an exception, there is
no way for execution flow to reach at end of function. Exceptions
should be handled properly.
Act-5: Implementing resource locking for shared resources and complete
transactions. Understand the thread safety mechanisms provided by
development framework and database.
Act-6: A structured approach must be followed for error handling. Sensitive
information or technical details like background operation causing
exception, stack traces, file system paths should not be disclosed in
error messages. Standard HTTP error codes should be handled by
application and never returned to users.
Act-7: Sensitive data should be transmitted to remote storage in an
encrypted and authenticated fashion.
Act-8: Choose a proper development framework, programming language with
respect to requirements and expected functionality as this decision
can mitigate much possible vulnerability.
Act-9: Applying least privileges and separating duties.
Act-10: storing sensitive data using appropriate access control and encryption
technique.
Act-11: Secure data transmission by using secure data transfer protocols
especially for sensitive data.
Act-12: validating remote codes including data type and size of uploaded
file or attachment.
Act-13: Filter unnecessary requests or decrease requests in order to avoid DoS
or low performance.
Act-14: Inactivity of users for a specific period should fore the system to log
out and login in again.
Act-15: Use library functions instead of using external / system calls. Avoid
invoking operating system calls directly.
Act-16: Simple Coding according to coding standards and well-defined
programming structure.
Act-17: Using validated SSL(secure socket Layer) certificates.
Act-18: In order to ensure that design is implemented in a correct and secure
way, code should be reviewed for issues like memory allocation and
free up , variable initialization. Tools are also available for automated
code review.
Act-19: Do not save password directly, encrypt them using appropriate
cryptographic function. For additional level of protection add
randomly generated data to user inputted password.
Act-20: Re-authenticate users before any critical transaction is authorized to
ensure that if a user session is compromised an attacker would not
be able to perform sensitive transaction on behalf of user unless
he/she is also in possession of user’s credentials.
 1
4
Act-21: Locking the account after predefined number of unsuccessful login
attempts and also increasing the response time after each failed login
attempt.
Act-22: Minimize the number of authentication interfaces.
Act-23: The application should be able to detect if a single source IP is
responsible for multiple authentication failures.
Act-24: Reissue a new token after successful authentication and protect it
throughout session’s lifespan.
Act-25: Session tokens need to be unpredictable and sufficiently random.
They should be independent on ser credentials. They must expire
after a reasonable period.
Act-26: Manage session to user mapping safely on server side.
Transmit session tokens over secure channel only. Use cookies to store them
not query string parameters.
Act-27: Set “Secure” and “HttpOnly ” flags to secure cookies and do not store
sensitive information in cookies.
Act-28: Deny access by default unless it is explicitly granted.
Act-29: Use parameterized queries and avoid string concatenation.
Act-30: Disable the functionality not required by application such as
operating system calls, HTTP interfaces, built in compilers, etc.
Act-31: Storing content outside the web root and using and indexed list of
accessible resources instead.
Act-32: Isolate the resource required by the application from other resources
in the underlying server.
Act-33: Store any uploaded content in a directory outside of web server’s
document root or best practice is to store it in database so that it can
not get executed by web server.
Act-34: Perform security focused code review. Ensure that dynamic execution
functions such as eval(), include() or those inside templates do not
take user-supplied data as inputs without strict validation.
Act-35: Do not use persistent cookies to store sensitive information.
Act-36: Instead o fusing query string, favor requests that send information as
HTML form parameter.
Act-37: Before performing requested operation make sure that requests are
legitimate.
Act-38: Token regeneration should be performed prior to any significant
transaction, after a certain number of requests, as a function of time.
Act-39: Do not rely on client-side security measures. Security must be
enforced by the server.
Act-40: Disable standard HTTP methods that are not used by application.
 1
5
Act-41: The Web server should run with minimum privileges required and
must apply security patches.
Act-42: Output validation with respect to type and amount of outputted
information based on security policies.
Act-43: Using stored procedures instead of dynamic SQL.
Act-44: Validating function’s return value and calling error/exception handlers
if required.
Act-45: Avoid hard coding of data.
Act-46: Re-implementing unsafe functions using standard library functions.
Act-47: Generating awareness among users and guiding them to differentiate
between original and phishing sites.
Act-48: Addressing with arrays instead of direct pointers manipulation.
Act-49: static creation of external commands in a program and passing static
string which can not be controlled by user, to format string function
and checking the number of arguments sent to that function.
Act-50: choose a proper and hard to guess location for temporary files and
applying access control mechanisms on them (encrypt if required).
Try to create lent side temporary files.

MAPPING ACTIONS TO VULNERABILITIES

This section shows the actions required to avoid a particular vulnerability in

tabular form. This mapping is done in such a way so that it becomes easier
for developers to implement it and understand the vulnerability. By
incorporating various security actions early in development life cycle,
developers can understand the threats faced by application and security
risks to which they expose organizations through application.

Vulnerabilit Actions Required

y
WV1 Act1, Act2, Act9, Act29,
Act34, Act42, Act43, Act39
WV2 Act1, Act2, Act9, Act34,
Act35, Act42
WV3 Act8, Act12, Act17, Act33
WV4 Act10, Act11, Act19, Act45
WV5 Act6, Act11, Act27,Act40,
Act41, Act44
WV6 Act7, Act10, Act20, Act24,
Act25, Act26,Act27, Act36
 1
6
WV7 Act24, Act38
WV8 Act1, Act8, Act9, Act34,
Act46, Act49
WV9 Act9, Act28, Act30, Act32,
Act39,Act40, Act 41
WV10 Act20, Act37
WV11 Act3, Act17, Act47
WV12 Act7, Act17
WV13 Act21, Act22, Act23
WV14 Act1, Act3, Act12, Act30,
Act31, Act32, Act33
WV15 Act1, Act8, Act18, Act48
WV16 Act1, Act5, Act16, Act29,
Act34, Act36, Act39, Act49,
Act50
WV17 Act5, Act13, Act14, Act15,
Act28, Act30, Act32, Act40
WV18 Act1, Act31, Act32, Act44
WV19 Act4, Act6, Act8
WV20 Act16, Act48
Table:2- Mapping actions to vulnerability

From the table2, it is clear that a vulnerability can be closed by taking

number of actions and a single activity can be essential in closing many
vulnerabilities. Depending on the action repeated in top 20 web
vulnerabilities, table 3 shows the no. of occurrences and most important few
actions that are essential to make web application more secure.

Actions No. of
occurrence
s
Act1 7
Act8 4
Act9 4
Act32 4
Act34 4
 1
7
Act17 3
Act30 3
Act39 3
Act40 3
Table3: Top Actions

These are the actions that are commonly overlooked by developers and have
given advantage to attackers. And most important thing is training and
awareness among developers to implement these actions in development
process.

CONCLUSION AND FUTURE RESEARCH DIRECTIONS

Implementation of security in early phases of development life cycle can
save time and cost of removing flaws after the software has been developed.
Relying on this idea of secure web development, this paper describes most
common known vulnerabilities and proposed model for software
development.
The activities described in this chapter do not grantee absolute secure web
applications but can help web applications to fortify against number of
attacks. It is very important that web developers keep themselves up to date
with new risks which their applications could face and also understand their
nature to ensure that the mitigations implemented are effective.

In the future, we can expect more security solutions and more awareness of
their implementation.

ADDITIONAL READING

Robert Seacord; “Top 10 Secure Coding

Practices”,
https://www.securecoding.cert.org/confluence/display/seccode/Top+10
+Secure+ Coding+Practices
Filippo Ricca, Paolo Tonella; “Analysis and Testing of web applications”
Proceedings of 23rd international onference on Software engineering
IEEE society page 25-34.
The Open Web Application Security Project (OWASP), “Secure Coding
Principles”, https://www.owasp.org/index.php/Secure_Coding_Principles
B001IQZDC0
Herbert H. Thompson, Scott G. Chase (2005); “Software
Vulnerability
Guide - Programming Series”, Charles River Media; 1 edition
Yao-Wen Huang, Fang Yu and Christian Hang, hung-Hung Tsai, Der- Tsai Lee,
and sy- Yen Kuo; “securing Web application code by static analysis and
run time protection” , 13th ACM International World wide conference,
2004
Secure Development Series: Secure Development Lifecycles whitepaper by
Apex Assurance Group, 2011.
Andrew cencini, Kevin Yu, Tony Chan; “Software vulnerabilities: Full ,
Responsible and Non-Disclosure”, 2005
 1
8
REFERENCES
 1
9
Bar-Gad I. and Klein A. (2002), “Developing Secure Web Applications”,
Sanctum inc. June 2002 available
at:
http://www.cgisecurity.com/lib/WhitePaper_DevelopingSecureWebApps.
pdf
Be’ery T., N.Shulman A. and Rachwald R. (2011), “Imperva’s Web application
attack Report -2011” , available at : http://www.imperva.com
Chunguang K., Qing M. and Hua C. (2006), “Analysis of software
vulnerability”, In Proceedings of the 5th WSEAS International
Conference on Information Security and Privacy (ISP'06), Nikos
Mastorakis and Antonella Cecchi (Eds.). World Scientific and
Engineering Academy and Society (WSEAS), Stevens Point, Wisconsin,
USA, 218-223.
[CUS] “Web App Security- Managing Web App Security Risks”, CUSIP (Web
App Security Working Group), March 2010, available at:
http://www.cusip.com/cusip
Davis N. (2005), “Secure Software Development Life Cycle Processes: A
Technology Scouting Report” December 2005.
[FOR] “Optimizing the Microsoft SDL for Secure Development”, Whitepaper,
Fortify Solutions to Strengthen and Streamline a Microsoft Security
Development Lifecycle Implementation, 2010.
http://www.fortify.com/servlet/download/public/
Optimizing_the_Microsoft_SDL_fo r_Secure_Development.pdf
Halkidis S. T., Tsantalis N., Chatzigeorgiou A. and Stephanides G, (2008).
Architectural Risk Analysis of Software Systems Based on Security
Patterns. IEEE Trans. Dependable and Secure Computing, Volume 5, Issue 3
, 129-142. DOI=10.1109/TDSC.2007.70240
http://dx.doi.org/10.1109/TDSC.2007.70240
Hajar M. J. and Salama A. M. (2011), "Implementing Case-Based Reasoning
Technique to Software Requirements Specifications Quality Analysis",
IJACT: International Journal of Advancements in Computing Technology,
vol. 3, no. 1, pp. 23-31, 2011.
[IBM] “Understanding Web Application Security Challenges”, Web Application
Security Management whitepaper by IBM, January-2008.
Jay-Evan J. Tevis and John A. Hamilton. 2004. Methods for the prevention,
detection and removal of software security vulnerabilities. In
Proceedings of the 42nd annual Southeast regional conference (ACM-SE 42).
ACM, New York, NY, USA, 197-202. DOI=10.1145/986537.986583
http://doi.acm.org/10.1145/986537.986583
Malek, M. (2004), “Security management of Web services”, Network
Operations and Management Symposium, 2004. NOMS 2004. IEEE/IFIP,
Volume 2, pp:175 – 189.
Metula E. (2012), “Web application attacks”, .NET Security User Group, from
2BSecure. microsoft.com/download/7/7/b/77b7a327.../m1-1p.pdf,
retrieved on 9 May, 2012.
th
 2
0
Michal H., David L. and John V. (2009), “19 Deadly sins of software security,
programming flaws and how to fix them”, McGraw-Hill Osborne Media,
1st Edition
 2
1
[MSD] “The Microsoft Security Development Lifecycle (SDL)”, Microsoft,
Version 5.0, 2010,
http://msdn.microsoft.com/en-us/security/cc448177.aspx
Nany R. Mead and Gary Mcgraw (2005), “A Portal For Software Security”,
Published by IEEE computer society, IEEE security & privacy, pp 75-79.
[OWA] “The Open Web Application Security Project (OWASP)”, Top Ten
Project Theme Page, available at: http://www.owasp.org/index.php/
Raviv Raz (2012), “Web application security, Cyber Fraud & Hacktivism”
available at: http://chaptersinwebsecurity.blogspot.com/
Shirazi H.M. (2009), “A New Model for Secure software Development”, In
Proceedings of International Journal of Intelligent Information
Technology Application, Volume 2, pp 136-143.
Steve L. & Michael H. (2005), “The Trustworthy Computing Security
Development Lifecycle”,

http://msdn.microsoft.com/security/default.aspx?pull=/library/en-
us/dnsecure/html/sdl.asp (2005).
[SYM] “Threat activity Trends- Web based attack report 2009-10” available
at: http://www.symantec.com/business/threat-report/
Uzi Ben-Artzi L. and Donald S. (2003),. “Web Application Security: A Survey
of Prevention Techniques against SQL Injection”, Thesis Stokholm
University/Royal Institute of Technology, June 2003.
Walker J. (2012), “web application security--keeping your application safe”,
http://ajaxexperience.techtarget.com/images/Presentations/Walker_Joe_
WebApp Security.pdf, retrieved on 9th May, 2012.
[WAS] “Web App Security—how to Minimize Prevalent risk of attacks”,
available at www.qualys.com
[WHW] “White Hat Website Security Statistic Report”, 10th edition Fall 2010,
available at www.whitehatsec.com
[WVR] “Webapps Vulnerability Report”, from Core Impact Professional, Jan
2009.
http://www.coresecurity.com/files/attachments/core_impact_webapps_v
ulnerabilit ies_report.pdf
Younan Y. (2003), “An Overview Of Common Programming Security
Vulnerabilities And Possible Solutions”, Master’s thesis, Vrije University
Brussel.