Study on Web Security Issues

Study on Web Security Issues

Abstract: Managing Web Application Security for an organization that engages in electronic business is a huge and complex task. Every entry point in the e-Business system must be secured, at both the network and application levels. Most of the network security issues, including access control, data transmission security, and authentication can be addressed using commercially available products, but application security has received less attention. Consequently, the application has remained the most vulnerable component in the security chain. Today, almost every e-Business web site can be broken into the application level in a matter of hours. Hacking techniques such as hidden field manipulation, parameter tampering, and cookie poisoning can be easily deployed, resulting in stolen customer data, denial of services, and the complete shut-down of the site. The vulnerabilities that permit these exploitations exist as a result of flaws in the design, implementation, and testing of internally developed code, as well as bugs and the misconfigurations of third-party products. It describe a new security technology, Web Application Shielding, a runtime application-level security proxy that automatically recognizes the application security policy for each page by constantly analysing the outgoing traffic from the web application to its clients. The proxy then automatically enforces this policy on returning requests, preventing hackers from exploiting application vulnerabilities and removing the need to track and patch every hole in the application. This not only provides a higher level of security, but also reduces security resource requirements within the organization.

Keywords: Web application, ROI, Web security, Web security approaches.

1. INTRODUCTION

Most of the business organizations in this current technology era depends on online software applications to conduct their operations. For this reason, web applications are subject to various types of attacks as hackers exploit vulnerabilities within the software like SQL Injection and XSS [1]. Malicious or silly users are also responsible for web security problems like users misuse the application to cause system failures or denial of service attacks, or attempt to discover web application vulnerabilities. To detect web-based attacks, intrusion detection systems (IDSs) are the most popular solutions to detect the web attacks. Unfortunately, it is hard to detect web application attacks due to the following two reasons. First, web applications are so specific and even the same applications might be deployed in different platforms, coded by different programmers or implemented by different programming languages. Second, IDSs must keep the

signatures updated with respect to the large numbers of vulnerabilities discovered daily.

It is going to raise a problem relating to system performance. Thus we cannot use the same signatures to defend the same attacks to different websites because the website vulnerabilities result from different software errors and programming skills. This paper presents an on-line user-behaviour surveillance system that detects the malevolent user behaviour and web application attacks using Embedded Markov model (EMM). The EMM proposed in this paper is a two-phase Markov model [3]. The first phase Markov model is used to establish the normal model for every attribute. The second phase is used to build the userbehaviour surveillance model for detecting the abnormal visiting behaviour. Our experiments show that our on-line user behaviour surveillance system is immediately useful to strengthen the on-line operating web security.

1. WEB SECURITY APPROACHES

   The following approaches can be followed to add security to online web applications.

   • Bolt-on approach

   • Do-it-all-up-front approach

   • Big-bang approach

   • Buckshot approach

   • All-or-nothing approach

Now we are mainly concentrated on working approaches, this approaches is used protect the security for the web applications.

So if bolting security on to your application or taking a buckshot approach isnt producing effective results, what works? The answer is a life-cycle approach, or baking security into your applications life cycle. By leveraging it in the development life cycle, you address security throughout development instead of up front, after the fact, or, worse, randomly. Infusing security into the life cycle is also a practical way to balance security with other quality attributes, such as performance, exibility, and usability.

B.ROI Activities

Clearly Return-on-investment (ROI) activities should be formed and applied entire development life cycle as a baseline set. For each of the scenario ROI activities be supplemented or modified accordingly. Most of the companies have some variations of the following activities, independent of any security focus:

• Design guidelines,

• Architecture and design review,

• Code review,

• Testing, and

• Deployment review.

  Identifying design guidelines involves putting together a set of recommendations for the development team. These recommendations address key engineering decisions (such as exception management) and include input from software vendor recommendations, corporate policies, industry practices, and patterns. Its a high ROI activity because it helps create the projects scaffolding.

  Architecture and design review is an exercise in evaluating the design against functional requirements, non-functional requirements, technological requirements, and constraints. It can be as simple as a white- board sketch, or it can involve multiple documents, diagrams, and presentations. An architecture and de- sign review is most valuable when its performed early enough to help shape your design. Its less valuable when its performed so late that its only function is to nd do overs.

  Code review is a practical and effective way to nd quality issues. Although you can nd some issues through static analysis tools, the advantage of a manual code re- view is contextual analysisfor example, you know the usage scenario and likely conditions.

  Testing is executable feedback for your software: it either works or it doesnt. Whether it works right is a bit trickier to establish. The ideal case is the one in which you establish an executable contract between your code and requirements, including functional, non-functional, and constraints. It also helps to know what youre looking for so you can test against it. Although testing is usually optimized around functional behaviour, you can tune it for quality attributes depending on your ability to set measurable objectives and de- ne what good looks like. Deployment review is an evaluation of your application as its deployed to your infrastructurewhere the rubber meets the road. This is where you evaluate the impact of conguration settings against runtime behaviour. A deployment review can be your last actionable check- point before going into production. Preferaby, you have a working build of the software early in its development cycle so that early deployment reviews can help reduce surprises going into production.

  These activities offer a high ROI because, if applied properly, they directly affect the softwares shape throughout the process. Ive seen these activities transform my customers results for the better, and they pro- vide key feedback and action at high-leverage points in the development process.

  III SECURITY ENGINEERING BASELINE ACTIVITIES

  Effective security activities based on the high ROI activities must be listed. However, rather than interspersing security in your existing activities, factor it into its own set of activities. This will help optimize your security efforts and create a lean framework for improving your

  engineering as you learn and respond. To inuence software security throughout the development life cycle, you can overlay a set of security-specic activities. Table 1 shows the key security activities in relation to standard development activities. The following is a set of baseline activities for security engineering:

• Objectives,

• Threat modelling,

• Design guidelines,

• Architecture and design review,

• Code review,

• Testing, and

• Deployment review.

  These activities complement one another and have a synergistic effect on your software security.

  1. OBJECTIVES

     To perform any job, you need to know where to start and when youre done. The security objectives activity is an explicit activity that helps you set boundaries and constraints for your softwares security so that you can prioritize security efforts and make any necessary trade- offs. Security is a quality attribute that you must balance with other quality attributes and competing concerns, as well as project constraints. You should identify up front how important security is for your particular project and context. Identifying security objectives helps you identify when youre done from a security perspective. A starting point might be to state what you dont want to happen with respect to securityfor example, you dont want to leak customer data or for one user to see an- other users data. For this activity, its important to rst agree what is inside the scope of your information security. It helps to think in terms of the informations condentially, integrity, and availability (CIA). You next decide which categories of objectives to work with. Using categories such as client data, compliance, quality of service, and intangible assets helps here.

     The following guidelines can help you identify your own security objectives:

     • Use scenarios to set bounds. Are operational requirements out of scope?

     • Ask yourself, Whats the worst thing that could happen from a security perspective? This helps you identify how important security is and where to spend more energy.

     • Turn objectives into requirements and constraints. Conversely, you can avoid common mistakes when identifying security objectives:

       • Dont try to gure out all your security objectives up front. What matters is that you identify the important ones that could have a cascading impact on your design.

  2. THREAT MODELLING

     We are familiar with your systems threats so that you know whether your security mechanism is effective or even warranted. Threat modelling, an engineering technique you

     can use to shape your software design, will help inform and rationalize your key security engineering decisions. In its simplest form, a threat model is an organized representation of relevant threats, attacks, and vulnerabilities to your system. During design, the most effective threat-modelling technique lets you quickly play out various what if scenarios [2]. Long before you implement an expensive countermeasure, you can quickly evaluate whether youre even going down the right path. You can certainly use threat modelling on a deployed system, but youll likely nd overlap with existing risk assessment activities. Risk assessments typically focus on the business risk, and often have an operational or infra- structure focus, so theyre not usually optimized for direct usage by the software engineer. In practice, Ive found the most successful threat modelling activities partition the infrastructure threat models from the applications.

     The following guidelines can help you build a threat model:

• Incrementally render your threat model. Model it to identify what you know, what you dont know, and what you need to know next.

• Use a question-driven approach. Whether youre guring out threats, attacks, or vulnerabilities, asking the right questions can lead you to better answers. You can even seed your questions with lists of questions that experts ask.

• Use a threat model to identify what code to prototype and test. Your threat model will likely reveal high-risk engineering decisions, which are great candidates to prioritize what to prototype or spike.

• Use complimentary techniques. You can use various techniques for nding threats, attacks, and vulnerabilities, such as use-case analysis, dataow analysis, question- driven approaches, roles matrices, and brainstorming.

• Use pattern-based frames. Theyre a conduit of insight from expert to practitioner and can signicantly help nd the low-hanging fruit as well as organize your thinking.

• Partition your threat-modelling activity within a predetermined time period. threat models. For some companies, partitioning by network, servers, desktops, and applications helps optimize relevancy and ownership. The key is to identify the important intersections between the application and infrastructure.

  1. DESIGN GUIDELINES

     Is your development team using proven software security design principles, practices, and patterns? If you havent pulled some together, you have less of a chance of success. The security guidelines activity is where you hunt and gather relevant security design advice and organize it in a way thats useful for your development team. This can include vendor recommendations and home-grown experience. A good guideline, however, will be more than just a description; it will be prescriptive. Use input validation is clearly a good idea, for instance, but it isnt a good guide- line. Lets turn that nice idea into something we can act on:

• What to do: Dont rely on client-side validation. Use it to help reduce the number of round trips to the server, but dont rely on it for security.

• Why: Serve side code should perform its own validation because an attacker might bypass your client or shut off your client-side script routines.

• How: Use an allow approach over deny. Its un- likely that you can dene all the possible variations of what bad input would look like. Instead, dene what good input looks like and lter for that.

  1. SYSTEM ARCHITECTURE

     Generally user behaviour surveillance system starts by extracting the different user visiting sequences from web traffic. Then, the analysis focuses on GET and POST requests. Our system architecture can be divided into two parts as shown in below Figure. One is user behaviour surveillance modelling system and the other is online user- behaviour surveillance defending system. We collect the specific website traffic and then process the user visiting data on the user behaviour surveillance modelling system. User visiting page transition, user query attribute values and all accessed web pages will be extracted from the web data and fed into EMM training model.

     Fig: 1 EMM Training Model

     The accuracy of all attributes for each page and the user visiting page transition sequences will link up to complete the user behaviour surveillance model. In the on-line defending system, we implemented thesoftware which was called the behaviour supervisor. The behaviour supervisor will monitor the user visiting behaviour and coordinate with user behaviour surveillance model to defend the user abnormal behaviour. When the behaviour supervisor finds the user abnormal behaviour, it will block the users connection and record the users information. Moreover, the normal traffic will be stored into real traffic collection database that will support our user behaviour surveillance model to be retrained. The retraining will gradually increase our systems accuracy and intelligence.

  2. CODE REVIEW

     Its important to keep in mind that some security choices are about following building codes or proven practices, while other choices are more about business risk. For

     example, following a vendor recommendation for a coding practice is closer to a building code, which might take the form of compliance rules, vendor recommendations, or your own policies. Other choices might be primarily driven by business risk. When youre faced with a few ways to solve a problem, in the absence of a clear coding practice, business risk is usually a driving factor. Many security practices become a combination of business risk and proven practice. At the end of the day, its your security objectives that help you know where to set the bar and how far to go Security experts use four common steps to per- form security code reviews:

     1. Identify security code review objectives. This is where you establish the reviews goals and constraints.

     2. Perform a preliminary scan. This involves using static analysis to nd an initial set of issues and improve your understanding of where you will most likely nd is- sues when you review the code more fully. The key here is to not get lost in the potential noise and false positives, but to see patterns of where to look further.

     3. Review code for security issues. This is where you review the code thoroughly to nd security vulnerabilities. You can use the results of Step 2 to focus your analysis. Here, techniques such as control- and dataow analysis come into play.

     4. Review for security issues unique to your architecture. This step is most important if youve implemented a custom security mechanism or any feature designed specically to handle known security issues.

  3. TESTING

     A lot of testing is requirements-based because requirements help dene an applications scope. The problem is that requirements are more about functionality than qualiers (such as what good enough security looks like). With performance, you can measure response time, throughput, and resource utilization. With security, its difcult to measure condentiality, integrity, and availability. The bar for knowing where to start, how to proceed, and when youre done goes back to your security objectives.

     The most effective, efcient security testing revolves around your security objectives and threat model. This doesnt dismiss possible benets from exploratory testing or discount penetration testing. In fact, its an industry practice to get a third-party to assess your software security when the stakes are high, which often includes penetration testing, both white and black box.

  4. DEPLOYMENT REVIEW

  Deployment is when your application meets the infra- structure, so deployment review is a great opportunity to assess the nal end game. Hopefully, production isnt the rst time you introduce your application to your deployment scenario. In practice, this often seems to be the case because I continue to hear horror stories in which an application roll out went bad or got blocked for reasons that an earlier deployment review would have caught.

  If you have a lot of knobs, switches, and desired set- tings or states, categories can help. A at list of settings can be

  overwhelming, and its tough to rationalize conicting lists, particularly from different sources with completely different lists. I like to organize the options by actionable categories. You might name a category Ac- counts, for example, and then identify the end state, based on principles:

• Accounts are least privilege,

• Strong password policies are enforced, and

• Separation of privileges is enforced.

  You can then quickly normalize compliance rules, infra- structure constraints, vendor recommendations, and so on. This also helps make checking more repeatable during deployment reviews.

  Conversely, you can avoid a common mistake: dont depend solely on your checklists. Theyre a great way to catch low-hanging fruit, but they dont replace thoughtful, contextual analysis.

  IV CATEGORIES IN THE WEB APPLICATION SECURITY FRAME:

  The following should be considered scrupulously for a robust application.

• Input and data validation,

• Authentication,

• Authorization,

• Conguration management

• Cryptography,

• Sensitive data,

• Exception management,

• Session management, and

• Auditing and logging.

Web application security is same as software security model with properties and attributes is a vital component in successful project development, often does not include sufficient attention to security concerns. The security considerations and issues must be addressed with application design, development, deployment, and maintenance in view, not during any one of these phases in isolation [4].

V CONCLUSION

The web application security advancements that we have discussed in this article without a doubt raise the bar in securing web applications by allowing web developers to establish an additional layer of defence as well as remediate the common web application vulnerabilities efficiently. While web developers are strongly recommended to investigate and leverage these techniques within their applications it should also be noted that the modern browser is a key component in the enforcement of these techniques. Hence these new techniques dont serve as a complete replacement to the existing remediation techniques since users not using the modern browsers would have no protection against the vulnerabilities that they remediate. The expert services and education to help organizations continuously and measurably protect their most important assets from the most critical threats. Through a strategic approach to security, Founds stone identifies and implements the right balance of technology,

people, and process to manage digital risk and leverage security investments more effectively.

VI REFERENCES

1. C. Kruegel, G. Vegan, Anomaly detection of web- based attacks, Conference on Computer and Communications Security, Proceedings of the 10th ACM conference on Computer and communications security, pp.251-261, 2003.

2. Threat Modelling Web Applications at http://msdn. Com/ThreatModeling.

3. P. Zhong, J. Chen, A Generalized Hidden Markov Model Approach for Web Information Extraction. IEEE/WIC/ACM International Conference on Web Intelligence, pp.709-718, 2006

4. D. Brumley, J. Newsome, D. Song, H. Wang; S. Jha. Towards automatic generation of vulnerability-based signatures. In Proceedings of the 2006 IEEE Symposium on Security and Privacy, pp.15-, 2006.