Server-side Statistics Scripting in PHP

On the UCLA Statistics WWW server there are a large number of demos and calculators that can be used in statistics teaching and research. Some of these demos require substantial amounts of computation, others mainly use graphics. These calculators and demos are implemented in various different ways, reflecting developments in WWW based computing. As usual, one of the main choices is between doing the work on the client-side (i.e. in the browser) or on the server-side (i.e. on our WWW server). Obviously, client-side computation puts fewer demands on the server. On the other hand, it requires that the client downloads Java applets, or installs plugins and/or helpers. If JavaScript is used, client-side computations will generally be slow. We also have to assume that the client is installed properly, and has the required capabilities. Requiring too much on the client-side has caused browsing machines such as Netscape Communicator to grow beyond all reasonable bounds, both in size and RAM requirements. Moreover requiring Java and JavaScript rules out such excellent browsers as Lynx or Emacs W3. For server-side computing, we can configure the server and its resources ourselves, and we need not worry about browser capabilities and configuration. Nothing needs to be downloaded, except the usual HTML pages and graphics. In the same way as on the client side, there is a scripting solution, where code is interpreted, or a ob ject-code solution using compiled code. For the server-side scripting, we use embedded languages, such as PHP/FI. The scripts in the HTML pages are interpreted by a CGI program, and the output of the CGI program is send to the clients. Of course the CGI program is compiled, but the statistics procedures will usually be interpreted, because PHP/FI does not have the appropriate functions in its scripting language. This will tend to be slow, because embedded languages do not deal efficiently with loops and similar constructs. Thus a first step towards greater efficiency is to compile the necessary primitives into the PHP/FI executable. This is easy to do, because the API is quite simple. In the extensions below, we have added the complete ranlib and dcdflib to PHP, plus some additional useful functions. The source code for these extensions, plus Solaris binaries for libranlib.a and libdcdf.a can be obtained from our server. Interpreting a PHP script, even with our new primitives, still requires starting up a CGI process for each page that is read. Again, this can be improved upon. We could use FastCGI to keep the CGI process around on a permanent basis. Instead, we have chosen a more direct method. PHP can be compiled as an Apache module, i.e. it can be compiled into the Apache HTTPD server binary. This means that PHP scripts are interpreted by the WWW server, which is always around, and which will fork additional children if necessary. No CGI processes need to be started. The PHP install process creates a libphp.a and mod_php.c in the Apache source directories, which can be used to build an enhanced server. This has the additional advantage of security, because all security features of the server can be used, and none of the pitfalls of using CGI or Java apply. Using PHP, in combination with the WWW server, also has some disadvantages. Although we can make simple static plots, using the gd library, we cannot use any dynamics, and interaction between the user and the page is somewhat limited. Java, or scripts using a client-side Xlisp-Stat as a helper, are more flexible in this respect. As a consequence, the UCLA Statistics pages still use a combined approach, with server-side PHP and CGI and client-side Xlisp-Stat and Java/JavaScript. Sometime this year, server-side Java scripting will become available, and then it seems advisable to switch as much of the code as possible to the server-side.

Server-side Statistics Scripting in PHP

On the UCLA Statistics WWW server there are a large number of demos and calculators that can be used in statistics teaching and research. Some of these demos require substantial amounts of computation, others mainly use graphics. These calculators and demos are implemented in various different ways, reflecting developments in WWW based computing. As usual, one of the main choices is between doing the work on the client-side (i.e. in the browser) or on the server-side (i.e. on our WWW server). Obviously, client-side computation puts fewer demands on the server. On the other hand, it requires that the client downloads Java applets, or installs plugins and/or helpers. If JavaScript is used, client-side computations will generally be slow. We also have to assume that the client is installed properly, and has the required capabilities. Requiring too much on the client-side has caused browsing machines such as Netscape Communicator to grow beyond all reasonable bounds, both in size and RAM requirements. Moreover requiring Java and JavaScript rules out such excellent browsers as Lynx or Emacs W3. For server-side computing, we can configure the server and its resources ourselves, and we need not worry about browser capabilities and configuration. Nothing needs to be downloaded, except the usual HTML pages and graphics. In the same way as on the client side, there is a scripting solution, where code is interpreted, or a ob ject-code solution using compiled code. For the server-side scripting, we use embedded languages, such as PHP/FI. The scripts in the HTML pages are interpreted by a CGI program, and the output of the CGI program is send to the clients. Of course the CGI program is compiled, but the statistics procedures will usually be interpreted, because PHP/FI does not have the appropriate functions in its scripting language. This will tend to be slow, because embedded languages do not deal efficiently with loops and similar constructs. Thus a first step towards greater efficiency is to compile the necessary primitives into the PHP/FI executable. This is easy to do, because the API is quite simple. In the extensions below, we have added the complete ranlib and dcdflib to PHP, plus some additional useful functions. The source code for these extensions, plus Solaris binaries for libranlib.a and libdcdf.a can be obtained from our server. Interpreting a PHP script, even with our new primitives, still requires starting up a CGI process for each page that is read. Again, this can be improved upon. We could use FastCGI to keep the CGI process around on a permanent basis. Instead, we have chosen a more direct method. PHP can be compiled as an Apache module, i.e. it can be compiled into the Apache HTTPD server binary. This means that PHP scripts are interpreted by the WWW server, which is always around, and which will fork additional children if necessary. No CGI processes need to be started. The PHP install process creates a libphp.a and mod_php.c in the Apache source directories, which can be used to build an enhanced server. This has the additional advantage of security, because all security features of the server can be used, and none of the pitfalls of using CGI or Java apply. Using PHP, in combination with the WWW server, also has some disadvantages. Although we can make simple static plots, using the gd library, we cannot use any dynamics, and interaction between the user and the page is somewhat limited. Java, or scripts using a client-side Xlisp-Stat as a helper, are more flexible in this respect. As a consequence, the UCLA Statistics pages still use a combined approach, with server-side PHP and CGI and client-side Xlisp-Stat and Java/JavaScript. Sometime this year, server-side Java scripting will become available, and then it seems advisable to switch as much of the code as possible to the server-side

Javascript

Cilj ovog rada je navesti i prikazati osnovne pojmove pri izradi web stranica, te detaljnije pojasniti skriptni jezik JavaScript i pokazati njegovu primjenu na specifičnom primjeru. JavaScript je najčešće korišteni client-side skriptni jezik. To znači da je JavaScript kod napisan unutar HTML stranice. Kada korisnik zatraži HTML stranicu s JavaScriptom, skripta se šalje na preglednik koji će napraviti određenu radnju. JavaScript je razvio Netscape da bi omogućio stvaranje dinamičkog web sadržaja. Iako sadrži mnoge značajke i strukture Java jezika, razvijen je zasebno. JavaScript može komunicirati sa HTML izvornim kodom, omogućavajući web dizajnerima da obogate stranice sa dinamičkim web sadržajem. JavaScript je potvrđen od strane brojnih softverskih kompanija te je otvoren jezik kojeg svatko može koristiti bez kupnje licence.The aim of this work is to go through the basic concepts of designing a website, and a to explain the scripting language JavaScript as well as to present its application to the specific case. JavaScript is the most commonly used client-side scripting language. This means that JavaScript code is written inside HTML pages. When a user requests an HTML page with JavaScript, the script is sent to the browser, which will do a certain action. JavaScript was developed by Netscape to enable the creation of dynamic web content. Although it contains many of the features and structures of the Java language, it was developed separately. JavaScript can interact with HTML source code, enabling Web designers to enrich the pages with dynamic web content. JavaScript is confirmed by a number of software companies and it is open language that anyone can use without buying a license

Javascript

Cilj ovog rada je navesti i prikazati osnovne pojmove pri izradi web stranica, te detaljnije pojasniti skriptni jezik JavaScript i pokazati njegovu primjenu na specifičnom primjeru. JavaScript je najčešće korišteni client-side skriptni jezik. To znači da je JavaScript kod napisan unutar HTML stranice. Kada korisnik zatraži HTML stranicu s JavaScriptom, skripta se šalje na preglednik koji će napraviti određenu radnju. JavaScript je razvio Netscape da bi omogućio stvaranje dinamičkog web sadržaja. Iako sadrži mnoge značajke i strukture Java jezika, razvijen je zasebno. JavaScript može komunicirati sa HTML izvornim kodom, omogućavajući web dizajnerima da obogate stranice sa dinamičkim web sadržajem. JavaScript je potvrđen od strane brojnih softverskih kompanija te je otvoren jezik kojeg svatko može koristiti bez kupnje licence.The aim of this work is to go through the basic concepts of designing a website, and a to explain the scripting language JavaScript as well as to present its application to the specific case. JavaScript is the most commonly used client-side scripting language. This means that JavaScript code is written inside HTML pages. When a user requests an HTML page with JavaScript, the script is sent to the browser, which will do a certain action. JavaScript was developed by Netscape to enable the creation of dynamic web content. Although it contains many of the features and structures of the Java language, it was developed separately. JavaScript can interact with HTML source code, enabling Web designers to enrich the pages with dynamic web content. JavaScript is confirmed by a number of software companies and it is open language that anyone can use without buying a license

Adaptive Hypermedia made simple using HTML/XML Style Sheet Selectors

This paper addresses enhancing HTML and XML with adaptation functionalities. The approach consists in using the path selectors of the HTML and XML style sheet languages CSS and XSLT for expressing content and navigation adaptation. Thus, the necessary extensions of the selector languages are minimal (a few additional constructs suffice), the processors of these languages can be kept almost unchanged, and no new algorithms are needed. In addition, XML is used for expressing the user model data like browsing history, browsing environment (such as device, location, time, etc.), and application data (such as user performances on exercises). The goal of the research presented here is not to propose novel forms or applications of adaptation, but instead to extend widespread web standards with adaptation functionalities. Essential features of the proposed approach are its simplicity and both the upwards and downwards compatibility of the extension

XSS attack prevention using DOM based filtering API

Cross-site scripting (XSS) is a type of vulnerability typically found in Web applications that enables users to input data and uses user submitted data without proper sanitation. XSS enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability present in web application may be used by attackers to bypass access controls such as the Same Origin Policy(SOP). Cross site-scripting is ranked 3rd among list of Top10 vulnerability mentioned in OWASP (Open Web Application Security Projects). Some of existing solutions to XSS attack include use of regular expressions to detect the presence of malicious dynamic content that can easily bypassed using parsing quirks and client side filtering mechanisms such as Noscript and Noxes tool which require security awareness by user that cannot be guaranteed. Some of existing solutions are unacceptably slow and can be bypassed .Some of them as too restrictive resulting in loss of functionality. In our work, we developed server side response filtering API that will allow benign HTML to pass through it but blocks harmful script. It does not require large amount of modification in existing web application. Proposed system is having high fidelity and low response time

XSS-FP: Browser Fingerprinting using HTML Parser Quirks

There are many scenarios in which inferring the type of a client browser is desirable, for instance to fight against session stealing. This is known as browser fingerprinting. This paper presents and evaluates a novel fingerprinting technique to determine the exact nature (browser type and version, eg Firefox 15) of a web-browser, exploiting HTML parser quirks exercised through XSS. Our experiments show that the exact version of a web browser can be determined with 71% of accuracy, and that only 6 tests are sufficient to quickly determine the exact family a web browser belongs to

Analysing the Security of Google's implementation of OpenID Connect

Many millions of users routinely use their Google accounts to log in to relying party (RP) websites supporting the Google OpenID Connect service. OpenID Connect, a newly standardised single-sign-on protocol, builds an identity layer on top of the OAuth 2.0 protocol, which has itself been widely adopted to support identity management services. It adds identity management functionality to the OAuth 2.0 system and allows an RP to obtain assurances regarding the authenticity of an end user. A number of authors have analysed the security of the OAuth 2.0 protocol, but whether OpenID Connect is secure in practice remains an open question. We report on a large-scale practical study of Google's implementation of OpenID Connect, involving forensic examination of 103 RP websites which support its use for sign-in. Our study reveals serious vulnerabilities of a number of types, all of which allow an attacker to log in to an RP website as a victim user. Further examination suggests that these vulnerabilities are caused by a combination of Google's design of its OpenID Connect service and RP developers making design decisions which sacrifice security for simplicity of implementation. We also give practical recommendations for both RPs and OPs to help improve the security of real world OpenID Connect systems