| Javascript Feeds RSS Feed Security Dashboard | SearchSecurity.com |
|
Apache
|
|
IIS
|
|
Web Proxy
|
|
Web Application Security - Layers of Protection This paper reviews some of the large number of resource s available for creating secure Web applications. These resources range from the security features of the development and database environments used, to automated tools evaluating an existing Web application, to Web sites dedicated to all facets of Web application security. Web application security is an extremely complex topic and by making one single mistake an otherwise secure application may be opened up to uninvited guests. By u sing the different resources available the risk borne by applications can be reduced to an acceptable level. In addition, some risk can be avoided at the very beginning of the project life cycle when the requirements for the system are defined.
03/24/2004
|
|
Information Security Issues in E-Commerce I will focus on some of the issues in the state of information security as it pertains to e-commerce. Areas that will be covered include the neglect for information security in the heads of e-commerce pioneers, intrusions and consequences that have been revealed to the general public, and a few notes about the future. It is perhaps those who consider security as a core function of ebusiness that will be the long-term beneficiaries of this revolution.
03/24/2004
|
|
Securing Server Side Java The Java platform began as applets running in client’s web browsers and promised to change the Internet. Java captured the interests of many in the computer industry for its ability to “write once, run anywhere.” The reality of the “Write once, run anywhere” marketing slogan did not quite live up to the hype. Although Java was and still is a good solution for cross platform client applications, it did not revolutionize client side applications over the Internet. However, one place that Java has made great strides has been with server side applications. This began when Sun Microsystems released the Java Servlet specification. Java Servlets became popular as a more secure and robust alternative to CGI. Since then, Sun has released Java 2, Enterprise Edition (J2EE) that is a specification for an enterprise-class server-centric Java platform. This document intends to provide methods and best practices to secure Server Side Java on the J2EE platform.
03/23/2004
|
|
Deploying a Secure Web Application: From a Coding Perspective The purpose of this document is to give a developer a very detailed and reproducible guideline for the development of a typical web application. The focus will be on common flaws that recently emerged in popular web applications. This guide will summarize and detail information regarding login page flaws, SQL injection, cross-site scripting/tracing, session ID hijacking and input validation. All of these vulnerabilities will be discussed from a coding perspective and will contain examples of secure implementations that avoid vulnerabilities. The focus is specifically on the coding aspect of development and can be used as a how-to guide for developing a secure web application.
03/23/2004
|
|
Web Security Appliance With Apache and mod_security As more and more attacks are being carried out over the HTTP layer there is a growing need to push the envelope and bring Web security to new levels. Most existing tools work on the TCP/IP level, failing to use the specifics of the HTTP protocol in their operation. The need for increased security has lead to the creation of application gateways, tools that are essentially reverse proxies with the added capability of protocol analysis. Many commercial solutions are available. This article will demonstrate how you can build your own application gateway with little effort, using open source components that are widely available.
03/22/2004
|
|
Why Web Application Security is the New Threat As the use and exploitation of the Internet matures, so does its need for security. Most seriously engineered Internet sites deploy firewalls and other similar techniques to restrict Internet access to limited ranges of network services. Although the hacking community continues to search for sites and networks that are over generous with the services and the number of services enabled, increasing effort is being placed into discovering and exploiting security flaws and weaknesses available in commonly offered services, namely web-based applications.
03/21/2004
|
|
Cross-Site Scripting Vulnerabilities A CSS vulnerability is caused by the failure of a site to validate user input before returning it to the client’s web-browser. The essence of cross-site scripting is that an intruder causes a legitimate web server to send a page to a victim's browser that contains malicious script or HTML of the intruder's choosing. The malicious script runs with the privileges of a legitimate script originating from the legitimate web server.
03/03/2004
|
|
Results of the Security in ActiveX Workshop That goal was achieved and the result of the workshop, this paper, serves not only to dispel unwarranted myths about the safety of using ActiveX but also to furnish guidance to network administrators and others faced with security issues involving mobile code in general and ActiveX in particular. ActiveX and similar mobile codes provide enhanced usability. The level of enhancement is significant enough for corporate and government users that Internet security policies and procedures should reflect 'risk management' rather than 'risk avoidance.'
03/03/2004
|
|
Fingerprinting Web Server Attacks In this article, zenomorph discusses multiple ways attackers attempt to exploit port 80 to gain control of a web server. Using this information, an administrator can learn to detect potential attacks and steps that are necessary to protect a server from them.
By zenomorph, 03/03/2004
|
|
Ten Steps to a Cleaner Web Root The first security policy I always implement for a web site is to keep the webroot clean. You cannot keep a secure site that is filled with clutter. Clutter includes anything that you do not explicitly use for your website. The problem is that clutter keeps gathering in our webroots. In fact, even a fresh IIS install contains quite a bit of junk you don't need. If you have the luxury of starting from a fresh IIS install, that is always the best. As time goes on it is easy to accumulate so much clutter in your web that it is hard to know what should stay and what should go. This document will be based on cleaning a default freshly installed IIS website so if you are working on an existing site you will have to consider some of these suggestions carefully before actually implementing them.
02/18/2004
|
|
Page: 123 4 5 |
