Task 1 – Functions and Advantages of Web Applications Stuttgart, 2008, states that the majority of websites online currently are actually in-fact applications, as they are dynamic and rely on a two-way flow of information and interactivity/interaction between the server and the client. This in stark contrast to the early days of the web, when websites mostly consisted of HTML pages containing static information.
Many of the functions one might associate with the modern Internet are in-fact conducted by applications: Common Web Application Functions User Authentication: It is important to be able to authenticate users accessing be services. This is for a several reasons, such as security/data protection and providing a personalized service. There are several mechanisms in which this can be accomplished, such as a Webster validating the client machine through their IP address/digital certificates/cookies etc.
Another, perhaps more familiar method for user authentication would be the use of login credentials (surnames and passwords etc). To perform this, web applications must provide: Information Storage and Recall: Although traditional web pages can be great providers of information, often the amounts of data squired may be too large to be feasibly placed directly in an HTML document. Additionally, all data/information stored on a website may not be relevant to most users, and they it’s likely they may only require a small portion of it.
Confidentiality of data can be important too, which is why the aforementioned user authentication functions of web applications can prove so beneficial. Finally, authorized users may need to add, edit or remove information from a website; in a static HTML document, potential laypeople could be expected to directly edit source-code. Things such as forums, studbooks and login systems all rely on this information storage, recall and manipulation. Relational databases are often a good solution to this need, and web applications can provide access to them (whilst validating the user’s credentials).
An example of a web application protocol doing such would be the integration of PH into Myself, which shall be discussed in further detail in section 2 of this report. E-Commerce: Through the use of the previously discussed functions, shopping online is possible. With the implementation and management of databases and the secure handling of data, along with authentication, sales can be facilitated online through the use of certain web applications. To make the experience user-friendly though, it is important to focus on: Interactivity in Lull (User Interface): Interactive elements on a website can be performed using web applications.
Benefits Many benefits arise from the use of online mediums for operations and distribution of computer programs. Here follows examples of such perks and the mechanisms in which they present themselves: Cross-platform: Web applications operate through browsers/plug-ins, and as a consequence can often function on a wide array of operating systems (whilst requiring only being written once, not subsequently ported across multiple platforms).
This advantageous concept has now began proliferating into the smartened market, as Yuan (2013) states, HTML based, multi-SO smartened APS are being developed as web applications to circumvent the problem of cross- platform incompatibility. Ubiquitous Accessibility: One of the biggest advantages of web applications (in comparison to their traditional counterparts) is that they can be accessible from anywhere in the world with a rudimentary computer and an Internet connection.
This can be especially useful for users who travel regularly, or for applications that are needed on- the-go (such as webbing). No Installation; Easy Distribution: As web applications are, for the most part, hosted entirely online, there is no need for users to install the software on their machines (provided they have browsers capable of running the web applications). Another advantage with this is that web applications are easily distributed; with traditional methods of application distribution physical mediums were often required, such as a CD or DVD.
When applications are based entirely online, distributing these hysterical objects is not necessary. This will firstly reduce overheads (as physical media costs money to produce, with Disregard, 201 5, offering 1,000 DVD’s pressed for IEEE) and allow for a much wider scope of sales (as the Internet is a global entity). Less Resource Intensive: When a web application is run, a large chunk of the computational work required can be conducted ‘in the cloud’; external servers can perform the requisite processing so domestic machines do not need to.
This can be beneficial as client machines have the potential to use software that their machines might not be physically capable f running themselves -? an example of this would be Online, where, according to Goldman, 2012, console games can be played on low specification PC’s, with all of the processing being performed on external servers. As long as the client machine could handle sending user controls/ commands, displaying sounds and images and the network communication, it could potentially render extremely graphically intensive games.
One issue that can arise from this though is the potential for the bandwidth to be too low and Internet connection too slow to handle the large volumes of data needed for smooth operation of the application. Finally, in terms of saving resources, drive space can be considerably freed up, if it is contained on an external server. From a theoretical perspective, one copy of an application on a powerful web server can provide said application to many, many users without said users needing to install it on their own machines.
Easy to update: With traditional installation mediums, updating required either having the user install the update from a physical medium or download a patch from the Internet. In comparison to web applications, this is an inefficient system for several reasons. Firstly, the logistics of getting all of the seer-base to update in a timely fashion gets increasingly difficult in such manners as a user-base grows – all users will need to either obtain a physical copy of the software update or download it from the internet for them all to be running the latest version.
Secondly, in terms of bandwidth, if all users had to download an update, then this would cause a lot of strain on the servers responsible. Thirdly, to be fully compatible with other users and all functions of the applications, it is often advised to run the most up-to-date version of said software – Bretons, 201 3, states that different versions Of games will to be able to play together. Web applications can mitigate all of these issues by simply updating the centralized, cloud-based (i. E. Coated on the physical Webster) application once, as all users will be accessing this version through their browsers. Task 2 Critical Comparison of Server-Side and Client-Side Scripting Languages in WAD Both client-side and sender-side scripting languages play significant roles in the development and deployment of web applications. These roles though, are often distinct and separate, with their own inherent advantages and disadvantages at performing given functions within the context of a web application.
Firstly, definitions, explanations and examples will be given of each of these types of language. From there, a comparison can be drawn, giving recommendations for some of the primary facilities that should be undertaken by each type of language: Client-Side Scripting Languages Canter, 2004, describes client-side scripting as languages that manipulate elements on a web page and that are performed and run on the client’s machine, usually on or through their browser. Thusly, a client-side script will be run locally, and the Webster running the website will not be used to run said application.
Flash, according to Watches, 201 5, runs on 11% of websites found to be using client-side scripting languages. As a positive, it can produce extremely aesthetically pleasing and interactive web elements. A downside to this though, is accessibility, though, according to Adobe, 201 5, it has implemented lots of features to try and mitigate this. Finally, Flash has some compatibility issues, especially with mobile devices; Apple, 2015 state that their phones and pads are not compatible with Flash.
Advantages A key benefit in using client-side scripting languages is that there is no delay if the server is busy/overloaded – use can feel more instantaneous. For example, if a website had many user interactive Lull elements, such a drop down menu, then the server would have to process each request of such an instance from every user that was accessing it. This leads to the potential of occupying heavy amounts of bandwidth and server processing capabilities unnecessarily, and thusly hampering the performance of the website for all users.
As such, using client-side scripting for such tasks has the benefit of alleviating stress from the server(s) involved. This helps the users enjoy a more stable experience (as they will not experience any delay in Lull elements) and, as mentioned, alleviate any unnecessary load on the Webster. Another benefit of client-side scripting is that they can be substituted with alternatives in some cases where compatibility is an issue. For instance, HTML has the potential to provide reasonable analogues to some of the functions traditionally associated with client-side web applications.
Disadvantages Compatibility could be an issue as not all browser support scripts. For example, Whalen, 2011, Lynx browser does not support Flash or Java, and Epiphany browser has issues rendering client-side scripts. It is also important to be aware that extensive testing of web applications using client-side scripting languages is likely to occur. This is for the reason that, according to Crawford, 2015, different browsers can render websites and applications differently. It is thusly important to ensure an application runs as intended on a multitude of different browsers simultaneously.
Another issue with client- side scripting is that the source code is viewable to all users -? this could especially be an issue if the script is intended to be proprietary, as plagiarism is made significantly easier. Additionally, functionality is often not as powerful as server-side, because of both hardware restrictions and security issues (the latter of which shall be explored in section 3 of this report). Server-Side Scripting Languages In contrast to client-side scripts, server scripts are often stored in HTML documents on the web server.
These scripts can then be called from different websites wishing to access them, and will return an output that can be embedded into the front-end page’s HTML and thusly outputted to the user. Common purposes There are numerous uses for server-side scripting languages. One of the most common uses is to allow a personalized experience for users through the facilitation of user accounts; PH, according to PH. Net, 201 5, originally stood for ‘Personal Home Page’. Database integration is another integral role undertaken by server-side scripting languages.
An example of this, according to Washcloths, 2015, would be PH’s ability to display and manipulate databases using Myself, which is, according to Oracle, 2015, the world’s most popular open-source database platform. Access to these databases through a web browser allows easier storage and recall of vast swathes of information. According to Wolfram, 201 5, some will take an input to calculate some sort of scientific/mathematical formula, work out said formula on a server and output the result to the user.
This is useful, especially for heavily intensive mutational tasks that may have trouble running on conventional machines (Wolfram’s, 201 5, state that they have terabytes of data in their computational engine). Examples of Server-Side Scripting Languages According to Watches, 201 5, PH is the most commonly used server-side scripting language with a market share, at time of writing, of 81. 9%. As stated by PH. NET, 2015, it is open source, making it free to use and modifiable.
ASP. NET: Stands for ‘Active Server Pages’, and is, according to Microsoft, 201 5, a proprietary language and platform for developing web applications. One limitation of ASP. NET is that it is generally only able to run on Windows servers, though it is worth noting that, according to Mono-Project, 201 5, there are software platforms that allow for ASP-NET applications to, in some cases, be cross-platform. Security is one obvious benefit of using server-side scripting languages.
As the script will be located on an external server and is not accessible to the client (as the website will act as an intermediary, taking input from users and outputting results from the server), it would not be possible for many exploits such as ASS (which will be discussed in section 3 Of this report). Additionally, the code will remain confidential, especially useful for commercial endeavourers. Larger amount of computing power should also be available with server-side scripts, as in the majority of cases a Webster will have superior hardware specifications to most domestic machines.
This gives the application the potential to perform advanced and intensive logical and arithmetical calculations that might not be feasible on the average consumer Disadvantages Slower response times are common, as requests need to travel from the user’s browser on their local machine to the server and then back again. The request will therefore likely take longer when taking into account travel time of the request. Servers can also get overloaded if too many users are on at the same time.
This can cause the server-side scripting elements of it to run considerably slower than usual. For instance, consider a website based in the UK with a predominantly British user base -? there is a chance they will have peak usage times, such as when most of their intended demographic finishes workshop etc. Applications based on this server will therefore likely experience slower response times due to system resources and bandwidth Ewing spread across a large multitude of users.
Compatibility limitations can occur too, since different servers can use a variety of operating systems that may not be compatible with certain languages. This is especially when dealing with proprietary languages. Conclusion It is essential to use the correct scripting method for a given task. One example of how efficient usage of scripting languages is outlined by Canter, 2004, who notes that running aesthetic scripting practices on the server-side will cause a significant increase in the bandwidth required of said server.
If en were to extrapolate from a single user accessing a server that encodes appearance-altering features, with any growth of user-base would come growth of the requisite bandwidth (and processing capabilities). Conversely, running server-side operations on client-machines can open-up applications to security threats, may not provide the performance needed and may display confidential and proprietary commercial source-code to all that wish to access it. Thusly, consideration over language type is imperative. Task 3 Analysis of Security issues that arise with Web Application Development
Despite the inherent benefits of web applications that have already been discussed, it is important to be aware of the potential security issues that can arise: One straightforward area of security weakness with web applications could simply that certain developers may not have viewed security as a key concern. In the design and implementation of a web application, organizations may be more concerned initially with the user interface, compatibility and general operation of the application than the security features.
This has been noted and empirically tested by Squibb et al, 201 5, ho have found that the agile design methodology is the most effective at ensuring higher consideration to security. This is likely due to the fact that agile methodologies are concerned heavily with threat testing – to make sure all potential issues (whether or not relating to security) are foreseen, considered, evaluated and alleviated where possible.
Here follows some examples and explanations of potential threats to web application security: Cross-Site Scripting (ASS) These are the most common attacks on websites, with Symantec, 2007, reporting that ASS on websites was responsible for roughly 84% of exploits hey had found. One can view these kinds of attacks as a type of hijacking of security privileges: The web footwork on a principle known as the ‘same origin policy. In essence, this policy allows scripts running from a one source to read data from a second web page if both have the same origin.
WWW, 2015, define the origin as the scheme, host and port of a URL. With this, nefarious hackers can insert specially crafted code snippets into standard user inputs on a website. If the web application architecture is not significantly protected against this kind of exploit, a client machine that views this code will execute he malicious script; it will trust the origin (from their perspective, the malicious came directly from the trusted website). One can view these kinds of attacks as the malicious code smuggling itself in with legitimate and trusted sources.
Even large, seemingly reputable firms have been the victim of ASS vulnerabilities – Eldon, 2008, reports that Backbone were the victims of such an attack. Web Server Security An application running on the Internet can only be as safe as the server it runs on. When a user accesses a web application, they are directly downloading information from a server. If said server is ever compromised, he user, through no fault of their own, can receive malicious software on their machines. Through ‘drive-by downloads’, in which harmful files are downloaded onto the client machine, users’ computers can be compromised.
These files can contain Edward, spare or files that can unwittingly take control Of a Users machine. Propos et al, 2007, notes that although the actual HTTP server itself can be compromised, one of the most common methods of breaching a server is through vulnerabilities in scripting applications, such as phoebe. Such vulnerabilities can actually allow unauthorized full access to the revere SO, and from there hackers can add links to malicious websites into standard templates – by including links to frames in a copyright boiler plate, every page on every site hosted on that server could infect any visiting user with malicious software.
Washcloths, 201 5, state that frames are ways to embed additional HTML files into other HTML files. By including HTML documents whose sole purpose is to download and execute malicious software, unbeknownst to the user, popular websites that are compromised can distribute huge amounts of such software. This threat is quite a inconsiderable one in scale, with Propos et a’, 2008, noting that around 1. 3% Google searches returned at least one malicious URL on the results page. User Contributed Content With Web 2. , a term and thesis first coined by Reilly, 2005, users are increasingly more involved in the creation, distribution and contribution of content to the Internet. This includes the actual creation of content and websites, with Wisped being a notable example of user-generated conglomerates surpassing the popularity of the traditional organizations, or through writing blobs, comments and/or the uploading of media. This, understandably, can have the potential to pose a few risks to websites and web applications.
One way in which user contributed content can pose a risk to web application security is through the insertion of HTML code snippets into an inadequately protected website. These inserts can contain scripts and frames, which can alter the way a page behaves, inadvertently linking to other websites (some of which can be used for drive-by downloading etc). In a similar approach, SQL injections target vulnerabilities in the architecture of a database.
SQL (Structured Query Language) is a widely used language signed to govern and dictate the behavior of relational databases, and according to SIS 2008, became a technical standard of the International Organization for Standardization in 1987. With an SQL injection, as stated by Parker et al, 2014, an SQL query is inputted to the database, by a nefarious user, which contains modified and unauthorized code. This code will be read by a vulnerable database, and cause it to act in ways not initially designed by the creators, for example outputting the confidential information stored in a database.
Though this poses no obvious risk, as advertisers’ reputation is intrinsically inked to their trustworthiness for content, the practices of Sub-syndication provides a mechanism for this to be an issue. According to Google, 201 5, sub syndication is the act of selling acquired advertising space and then selling it on to a third party. An issue arises when this is repeated several times for the same advertising space; with each consecutive step in this chain of advertisement sub-syndication, linking to malicious code becomes increasingly difficult to attribute blame to any one individual advertiser.
It works by analyzing all requests made to a server and checking them for SQL injections, character encoding and buffer overflow attacks. Monitoring the traffic and deciding each requests purpose, through algorithms to detect such behavior, helps to significantly reduce the risk of such attacks. Additionally, it is vital that correct provisions are made when using Web Application Firewalls.
Holm et al, 201 3, note that Web Application Firewalls are about 80% effective if the following steps are taken: a) A skilled and experienced operator monitors the firewall b) Automated black-box testing is used when tuning the firewall c) The individual tuning of the firewall has been done by an experienced professional d) Careful consideration and a lot of resources have been voted to the fine-tuning of the firewall. The same study also found that if none of these steps were followed, the success rate of the Web Application Firewall dropped to around 25%.
Another method of improving the performance of a Web Application Firewall is to Unguent et al, 2013, is to apply computational intelligence models, that, through machine learning, improve themselves over time through monitoring the success of various tracking strategies. Quality Control on Advertisers As discussed, advertising can be one route that can compromise the safety of a web application. By making sure one’s advertisers are reputable and do not low practices such as sub-syndication, one can help mitigate the chances of advertisers compromising the web application’s security.
Another sign efficient issue that arises from poor choices in advertisers is the proliferation’s of click- boot operations, which, according to Miller et al, 2011 , generate computer- generated ‘clicks’ on advertisements to mimic human behavior. Such technology is often utilized by middlemen in sub-syndication chains, selling the additional traffic to produce fraudulent results and bolster profits. Thusly, special care should be taken when deciding on any advertising in a web application. Proper Coding Practice A large bulk of web application security vulnerabilities can be attributed to design flaws.
As described by Kern, 2014, issues arise from insufficient sanitation and validation of external strings (i. E. Inputs from application users). Fundamentally, this means an effective means of mitigating these types of attacks is designing applications in such a way that any inputs aside from those intended/authorized by the designers should be expressly forbidden. By ensuring that any comment boxes or other interactive areas Of a site will only accept valid inputs and regularly discard any scripts or code nippiest that could cause the site to perform any unintended actions, ASS attacks are harder to perpetrate.