Security Web Programmers are often not given the clout nor the attention they deserve. Security programmers apply a much higher degree of attention, detail, and time to programming. Secure software may require more time and money than insecure software. A comparison must be made between the cost of securing web applications, and an insecure web application bringing the business down or releasing sensitive information to potentially nefarious hackers.

Don’t be misled by security misnomers or be mistaken about your security requirements. Security factors can be well-defined and explained at any level of your corporate structure. Emagined Security employs security programmers who are trained and experienced to develop secure software, including web and database applications. Our proven security programming techniques and multi-layered security development protocols ensure your web applications are protected and your sensitive information secured.

Issue 1: Lack of Data Validation & Data Cleansing
Information sent to your server from web requests that is not validated and cleansed before being handled by a web application produces an environment for attacks. The vast majority of compromised servers are broken as a result of this security vulnerability. A common security misnomer is that, “my firewall will protect my server.” Firewalls may limit the traffic that reaches your web applications, but a poorly developed web application creates vulnerabilities to traffic that firewalls do not filter or prevent.

Resolution 1: Wherever a user may submit information to your server, there is a requirement for data validation and data cleansing. From a programming point of view, any information that reaches a web application can be inspected for filtration, rejection, or approval prior to being handled by the expected web application modules. Whereas a firewall does not filter traffic, an IDS (Intrusion Detection System) can inspect traffic for predefined attack patterns prior to reaching the web application, and is advised. A common security misnomer is that SSL (Secure Socket Layers) will protect your customers, yet can create another layer of security vulnerabilities, if traffic is decrypted after passing through the IDS rather than before. IDS does not decrypt traffic, so SSL-encrypted traffic must be decrypted prior to the IDS, allowing IDS to inspect “plain traffic data” for attack patterns.

At the programming level, web applications should inspect all incoming data for attacks and abuse to create a layer of web application security. Bear in mind that some scripts may accept traffic from sources other than the expected web forms and points of origin. A hacker may submit a form via a POST request directly to the server without ever visiting the web site or using a web form. Data types can be modified easily and re–submitted multiple times in an attack. The web application should be designed to handle a specific data set of expected data types, not to accept any or all submitted data. Every Value sent to the server has a Variable that can be addressed individually for the expected format, pattern, content, and illegal characters.

A simplified example of data submission and data validation and data cleansing would be the simple newsletter signup form. The user is expected to submit an email address, which the server would place into a database for storage and perhaps send an alert email to the newsletter manager. Three critical points of programming come into play here. The email address is handled by code, the database is updated with the supplied email address, and an email is sent using the email address. The vulnerability arises when the insecure programmer assumes a nice shiny belief that the only data submitted will be an email address. The exploitation arises when the hacker submits something ther than an email address, such as a String of Code, an SQL Injection, or another attack. Without programming-level measures in place, the web applicati0n may be compromised, not to mention the server, the database, and sensitive information as well.

Data Validation is a security programming technique that inspects the submitted “email address” to determine if the pattern matches that of a real email address format. If the data does not meet the requirements for being an email address, the data is dropped and the user messaged to say that the web application is not vulnerable, hopefully diminishing ongoing attacks. Data sent as an attack should certainly not be sent to the database, but it can be modified for administrator review and inserted into security logs or emailed inside an alert. Data Cleansing is the process of removing illegal characters or patterns, and rendering attack strings inert so they may be handled by the web application.

Beware the common mistakes of assuming a radio button or checkbox will not create a point of data tampering. Attackers can send anything they want to a web application using the variable names of anything they define, including radio buttons, checkboxes, and file upload fields using standard POST/GET requests and using AJAX connection methods. AJAX (and Javascript in general) have created a large resource of attack points for exploitation since a larger assumption is made by insecure programmers that the AJAX connections will not become points of attack, for the same reasons they assume for form objects.

Issue 2: Broken or Lacking Access Controls
Member-Restricted and Administrator-Restricted access is often granted to provide control over websites, databases, and various information types. When there is a lack of control over who accesses data and which restrictions really apply, attackers may access accounts, sensitive information, and levels of administration that they should not. A member who gains access to administration functions that delete members or downloads a copy of the database is not a good thing, and can destroy member and investor loyalty. This vulnerability will not meet HIPPA Compliance, PCI Compliance, and other compliance mandates in different industries such as the medical and financial sectors.

Issue 3: Broken or Lacking Authentication and Session Management
Restricting access to a web application, and the data it is supposed to protect, requires protecting the access credentials and authentication schemes. A common attack to gain access rights of other users is called Sessi0n Hijacking. Sessions are closely associated with Cookies, and together these storeUser Names, Passwords, Access Keys, and other vital information used to allow or deny access to sensitive information. Cookies are stored in user browsers where sessions are stored on the hosting server.

Secure techniques allow the storage of sensitive authentication tokens in the session only, not the cookie, and use the cookie only to store the Session ID that connect the cookie (browser) to the correct server-side session. Secure server configurations are required to assure randomized session ID values that are not easily predicted and to assure storage of sessions is secure. Sessions must track a fingerprint of the user, including the IP Address, browser type and language, platform, and other trackable data types for fingerprinting. Tracking the time the session started and restricting its duration of use is another useful security technique. The concern is that a hacker may copy the session ID from the transmission between the user and the server, then integrate that session into the traffic on another machine and access the user’s account and web application functions.

Resolution 2 & 3: Securing sessions may impede Session Hijacking, but there is another layer of programming required for authentication schemes to operate securely. Data Validation and Data Cleansing (ab0ve) must be employed in all transactions. Enforcement of unique user names must be employed to prevent users with the same User Name from accessing incorrect accounts. A well-defined access control list should determine what the user may access, not a list of what the user may “not” access. Authentication and access control modules should be integrated into a single modules or system and applied globally, allowing global updates and corrections. SSL encryption should be used to help prevent attackers from listening to the traffic for sensitive information, and SSL Enforcement is advised. Unathorized access attempts should be logged and alerts sent for review and potential remediation.

When new modules are added for user access, a complete security review must be performed to assure vulnerabilities have not been introduced. When systems that require authentication are hostedd on the same server ass systems not requiring authentication, the security programmers should review the insecure programming modules for vulnerabilities to their systems, else host the authentication-restricted media on a separate server. Security vulnerability assessments should be scheduled and performed as a routine security measure. Although there are other techniques and aspects to securing authentication systems, these measures are a good basic review.

Issue 4: Cross-Site Scripting (XSS) Vulnerabilities
Cross-Site Scripting is an attack method that introduces remote web components into the host site, or transports the site user to a remote web site. The goal of the attacker is to make the user execute remote code or modules that reveal user authentication, sensitive information, or create access to the host site in some form.  Methods of attack include inserting XSS code into the host database, using methods such as Code Injection or SQL Injection. The attacker may modify the web file code on the host server to include Active-X controls, redirection methods, iFramed content, or other attack types. The results of these XSS attacks range from revealing authentication credentials to feeding sensitive information to a remote user or host, proprgating the attack to other members or administrators of the site, and creating Man-in-the-Middle attacks such as Phishing attacks. Some attacks may become visible immediately with or without repercussions, while other may reside actively or latent on the host server feeding data to remote hackers regularly or waiting for a trigger to launch a more complex or timed attack.

Resolution 4: XSS Cross Site Scripting requires due diligence of a security programmer and includes other resolution description above and below. The vast majority of web application exploitations result from poor programming. Server configurations such as Magic Quotes and Strip Tags may reduce the chance of injections from being successful. Correctly placed and configured IDS with updated match patterns helps reduce the chance of attack traffic from reaching the web application. Most importantly, Data Validation and Data Cleansing must be included at every level of security programming to protect the web application from many various attacks.

Issue 5: Buffer Overflow Vulnerabilities
Some web application components in some languages do not correctly validate user-submitted input and may crash or freeze a server. IN some situations a Buffer Overflow may used to take control of a process, despite being difficult to execute. Vulnerable components can include CGs, DLLLibraries, Various Drivers, and some web application server components. This attack is performed by submitting more information than a variable is expecteing 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.

Resolution 5: In most cases, buffer overflows are not the responsibility of the security programmer as much as that of the server administrator. The physical server itself must be correctly configured and updated with the latest security features and patches. Vulnerabilities in languages asuch as ASP, PHP, CFM and others must be addressed by the developers or communities and the updates and upgrades applied quickly. Hackers are just as well-informed about buffer overflow problems in software as the security professionals, since buffer overflow problems are almost always public information.

If the hacker knows what version of server software you utilize, and a security vulnerability is announced for your version, that hacker may immediately attack your server with a well-defined attack point. For this reason, your server should never announce which type or version of software is running. In fact, the option exists to mislead the attacker by declaring a different server software name or version.

Buffer overflows are not easy to execute successfully and usually require multiple attack attempts. Keeping your server up to date for all software packages is required, and using an updated and correctly placed IDS is important. There is not much a security programmer can do to mediate buffer overflow attacks, but data validation may reveal attacks of this nature and alerts may be used to bring attention to logs and advise admins to look for attacks and their sources.

Issue 6: Code Injection & SQL Injection Vulnerabilities
This is my favorite aspect of hacking, since it is very much a programming-level attack technique. Referring to the email address and newsletter signup example above, an incorrectly programmed handler of submitted data may allow unexpected data to exploit the web application or server. An SQL Injection is a type of Code Injection. A Code Injection sends programmer’s code to the server inside a variable. If the web application (or IDS) does not identify the variable’s contents as invalid, the code that is sent may be executed by the web application. An SQL Injection is a specific type of Code Injection in which the web application’s database is the target of the attack.

Code Injections may come in many flavors that include anything your programming language can perform, given permissions restrictions on the server. In the newsletter signup example, the expected value is a regular email address. However, if that variable contains a section of code that is correctly written to insert itself into the server-side web application code, the server may execute the targeted script including the attacker’s code. Given the range of possibilities defined by the language itself, the worst case scenario is that the code creates a situation allowing the upload of a root kit to the server and the whole server is owned by the attacker.

SQL Injections are the same as a Code Injection except that the target of the attack is the database. Using Sequel Querying Language (SQL), the injected code may connect to the database to delete all contents, feed the entire database to the remote hacker, insert whatever records the hacker defines, or modify existing records. Using an eCommerce system as another example, an attacker may wish to retrieve credit card profiles or create records causing the business to deliver products or services without being paid.

Resolution 6: Employing Data Validation and Data Cleansing techniques from above, SQL Injections may be easily mediated.  Techniques include individual value inspection, configuring the web application to use Magic Quotes, and configuring the web server language and database to handle cases of string escaping.  Deprecated methods such as using “mysql_escape_string()” must be remediated with modern code or higher value techniques. Data Cleansing and Validation is the bottom line for preventing Code and SQL Injection attacks. Where SQL Injection attacks may be difficult to identify without IDS or advanced SQL Injection prevention programming techniques, slash notation handling may be required.

Given a website that stores samples of SQL Queries and commands for SQL researchers, a text field may contains SQL string that will be tough to differentiate from SQL Injection attempts. Although this is an uncommon situation, it illustrates the fact that there are times you simply accept the data and “add slashes” to the data so it is not executed by the server or database. Magic Quotes is another example of server language and programming-level technique for mediating SQL or Code Injections.

Issue 7: Poor or Lacking Error Handling
Errors can be created on almost every web application, but the difference between a crafted web application and a poor web application is how the error is handled. 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 the 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. The nature of the potential vulnerabilty depends on the nature of the mishandled error and the server or web application environment.

Resolution 7: All errors must be handled either with specific error handlers for expected errors, or with broad error handling mechanisms for unexpected errors. The server should not operate in debug mode once launched into production, and development systems must be kept inside intranets (or securely on the Internet) where they may operate safely in debug mode. At the server level, all errors may be written to error logs regardless of being in production mode instead of debug mode. The amoutn  of logging is independent of the operation mode, so logging may remain in debug mode while the server is not in debug mode. The pages that result from errors should specifically or generally return a designed web page containing navigation back into the site, no debugging content for general users, and not reveal the facts related to a true error. General users will return to the site unaware that there was an error, while attackers may be misinformed to think their attacks did not succeed.

Issue 8: Insecure & Improper Data & File Storage
All too often poorly programmed websites provide easy access to credit card profiles, restricted areas of the web application, and to sensitive documents and information. Information and file management is a growing concern and must be addressed. Information stored in databases may not be protected by authentication or encryption. Sensitive files stored on the server may be directly browsed simply by side-stepping authentication. Authentication techniques may be incorrectly applied or insufficient to protect data and files.

Resolution 8: Correctly securing data and files requires two different approaches to the same results. Data stored in the database requires different security techniques from files stored on the server, yet there are some techniques that are the same. The type of data stored inside the database record or file may affect the technique for securing the content.

Protecting simple passwords may be as simple as using one-way or two-way encryption, depending on the type of server the web application is hosted on. One-way encryption means the user’s password is encrypted using the same one-way encryption then compared against the encrypted password in the database. Failure requires the password be changed via some other mechanism, which can create vulnerabilities in itself. Two-way encryption may be the decryption of the password stored in the database and comparison against the submitted password. If the server is a shared hosting server, one-way encryption is necessary, yet may become a moot point when misconfigured web hosts allow neighboring web applications access to browse the web files that contain the encryption/decryption code.

File storage is a somewhat different issue since the information is stored as flat files on the file system. If possible, store the files outside of the web root, where permissions are more restricted. Do not store files with the original file name of file URI. Track the files and use a file name that is a tracking ID without a file extension. Stream the file contents to the user and name the file on-the-fly.

Issue 9: Denial of Service Vulnerability
A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer resource unavailable to its intended users. Although the means to perform a DoS attack may vary, it generally consists of concerted efforts to prevent an Internet site or service from functioning efficiently or at all. DoS attackers typically target sites or services hosted on high-profile web servers such as banks, credit card payment gateways, and even root nameservers. The term is generally used with regards to computer networks, but is not limited to this field, for example, it is also used in reference to CPU resource management.

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 effectively unavailable. In general terms, DoS attacks are implemented by either forcing the targeted computer(s) to reset, or consuming its resources so that it can no longer provide its intended service or obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.

Resolution 9: Preventing Dos and DDoS attacks requires the integration of multiple prevention techniques. Firewalls can limit the traffic to the server. Switches and Routers that can handle high volume traffic are often able to detect and limit throughput based on too much traffic or a detected DoS attack. Front-end application hardware in conjunction with switches and routers may identify and handle traffic ans normal, priority or potentially dangerous. IP Based restrictions may help throttle traffic and limit or mediate DoS attacks. Blackholing (sinkholing) may be used to redirect DoS traffic to dead-end IPs and destinations. Low-volume web environments may make more use of programming-level prevention, but DoS/DDoS prevention is more of a server and network level remediation approach.

Issue 10: Lacking or Poor Configuration Management
A poorly or incorrectly configured server and server modules will potentially create multiple security vulnerabilities. Network configuration is also important for securing the server and its environment. A secure web application requires a strong server configuration. Many servers and software packages are distributed with an insecure configuration out of the box. A default server may have many features turned on for convenience, including Open STMP Relay,  Anonymous FTP access, and other insecure features which may be desired after being reconfigured. Some defauly systems 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.

Resolution 10: 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. Before putting the server into production, a security vulnerability scan should be performed, followed by a code review of the web application.

Emagined Security
If you have questions about Secure Web Programming, or have concerns about your current web applications, you may contact me at andrewlandsman at emagined dot com or call Emagined™ at 888.235.1906 for a Security Consultation.

A Web Programmer is typically involved in a server-side language such as PHP, ASP, and other languages that are optimized for web applications. My specialty is Secure PHP & MySQL programming, especially for web and database programming applications. This does not negate the ability to comment on web security for ASP and other languages, as they all operate pretty much the same, just with different command structures and spellings. Data flows the same way, and potential security vulnerabilities are about the same. The only exceptions are associated with a Microsoft Web Server, which inherently provides regular security flaws and problems.

The question that arises is, “What is ‘secure web programming‘ as opposed to other types of programming?” This is a basic question that is most often overlooked by companies seeking programming assistance. A programmer is in a nutshell a person who writes code to build some sort of dynamic behavior or application to meet the needs of various projects. The sky is the limit on what the dynamics could be. They range from sophisticated scanning, response, and production systems, all the way down to a simple email address submit field for the local security news letter.

What sets a Security Programmer apart from other programmers is the attention to security. The vast majority of programmers have little or no understanding of true security, and produce copious amounts of security vulnerabilities for unsuspecting customers and companies. Where the regular web programmer is ignorant of security, the true security programmer designs and writes the code for applications with security in mind during every step of production. More than a few times I’ve heard programmers preach their knowledge of security, only to reveal their true lack of knowledge. It is an unfortunate reality that most customers cannot differentiate the security programmer from the ignorant programmer who makes great claims of understanding security. Unfortunately, it is a caveat that customers must beware on their own account, lest they fall victim to poor programming and to watch their Online business dissolve from attacks and the repercussions that follow.

Wikipedia: http://en.wikipedia.org/wiki/Defensive_programming
Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software. The idea can be viewed as reducing or eliminating the prospect of Murphy’s Law having effect. Defensive programming techniques are used especially when a piece of software could be misused mischievously or inadvertently to catastrophic effect.

Defensive programming is an approach to improve software and source code, in terms of:

• General quality – Reducing the number of software bugs and problems.
• Making the source code comprehensible – the source code should be readable and understandable so it is approved in a code audit.
• Making the software behave in a predictable manner despite unexpected inputs or user actions.

The scope of this article is Secure Web Programming. Security Programming extends into many other mediums aside from web sites and web applications. Programmers who work with Java, C, C++ and other similar languages must observe similar protocols of Security Programming, else their applications may fal victom to many types of security vulnerabilities, both similar to and dissimilar from security vulnerabilities in web applications and programming.

Below are a few methods of attack that a Secure Web Programmer must be aware of, and have an expert understanding of to perform true Secure Web Programming.

Code Injection: Web servers may accept submitted data from web pages, or directly from intermediate sources, such as man-in-the-middle attacks. If the server-side application is not designed to recognize code from regular text submissions, the submitted code may be executed and the security vulnerability subsequently becomes a security exploit.

SQL Injection: Similar to Code Injection above, an SQL Injection submits a query structure or query modification to the server that is subsequently passed to the database for handling. If the SQL data submittedd is not filtered or rejected, the database may perform the submitted instructions. This may result in all database information streaming to the attacker, which may then be used for subsequent attacks, publication to the world, or attempts for monetary gain. As well, the database may be altered or even deleted, rendering the web application worthless.

Denial of Service (DOS): Web applications that are attacked with DOS may no longer respond to valid requests, may shut down and stop working, or result in the creation of security vulnerabilities that may be exploited. Although most DOS attacks simply render web servers unable to respond to real visitors’ requests, the web server may “break” instead and possibly allow other types of attacks to subsequently provide access to hackers for exploitation.

Buffer Overflow: A Buffer Overflow attack is when the amount of data submitted exceeds the allocated space to receive and handle it by the server, usually dictated by the web server application settings, and sometimes y the programmer. When the allocated space is insufficient for the submitted data, and the data is accepted, the additional data that was unexpected may overwrite adjacent memory space. The result may include system and application malfunctions and forms of security vulnerabilities.

In addition, there are external protocols to observe for the Big Picture of Secure Web Programming. Security Programming extends beyond the code itself, and into the realm of publc domain. Information handling includes both Internal and External displays of information, for both restricted and unrestricted access. It is not uncommon for a programmer with only code-level security experience to create a secure and valid application, which allowss the customer or admin to accidentally make more iformation public and external than intended.

Information Dissemination: Using credit card profiles for an example, some web applications may allow an admin to store sensitive information in a non-sensitive context. Although the admin may be secure from a server-side perspective, the information itself might be revealed to the world. Although the application may not be vulnerable to attack, the issue of securing the data itself may not have been handled correctly or appropriately.

Google Hacking: Once information is disseminated, it is likely that Google will index it and make it even more accessible to attackers. Google hacking, as coined by Johnny Long (the famous Google Hacker expert), is the art and science of using Google’s search features to specify very specific search criteria, resulting in unexpected results. For example, if the credit card information above had been disseminated via a public external medium, and Google managedd to index it, a Googlee hacker would quickly find that information and use it for their own purposes.

Note: Court systems and Police Departments will publicize your credit card information, if your purse or wallet was stolen and you are dumb enough to give the details to the officer. Not only will your credit card information be made immediately public, so too will your fukll name, home address, and other personal information. If your card is stolen, you had better call the credit card company first, before the police help Google Hackers abuse your account!

Now comes the question of, “How do I protect my web applications?” My first response to this questions is, “Make sure your programmer really does have expert knowledge and experience with security.” Anyone can buy a book on programming and build a simple email address submission form. This does not mean they are true programmers. Any programmer can buy a book on security and make grand claims of being a “hacker,” which may garner them some weekend dates, but does not make them security programmers. What differentiates a Joe Blow from a programmer is the same thing that differentiates a Programmer from a Secure Web Programmer; Experience and Expertise.

Code Audits & Code Reviews: If your web applications are already built, or have been significantly changed or updated, you may want to consider a Code Review. Especially when applications are developed by programmers who are unaware of security, a Code Review may reveal the security flaws that exist, point out where the reside, and define how to resolve them. If your programmer is not a Security Web Programmer, your next best option is to have a Code Review. In some cases, companies may opt for a Code Review as a third-party assessment to assure their secure web programmers did not miss anything.

Make sure your potential “Secure Web Programmer” provides a portfolio of past programming and security work, has reliable business references that declare that person’s programming and security skills as valid and expert, and make sure you communicate extremely well with that person so they understand your business, the project and all of its potential caveats before they start writing code. Programmers that hide in dark corners and reject communication for fear of making a friend should be managed more closely, because they are likely to miss the boat and go the wrong direction for lack of understanding the project at hand. You may have the smartest code writer around, but if there is a lack of communication, how can they build the most appropriate system to meet your business needs, and how will they protect it if they don’t understand the Big Picture? Most importantly, do NOT negate Security as a major component in developing your web applications!!

If you have questions about Secure Web Programming, or have concerns about your current web applications, you may contact me at andrewlandsman at emagined dot com or call Emagined™ at 888.235.1906 for a Security Consultation.

The types and degree of security vulnerabilities to your network and applications depends on what your applications are designed to do and how good the programmers were. Threat modeling is required to develop a methodology for the approach to secur auditing, leading to the actual code inspection. Subsequentt to the process of modeling, a triage list of inspection points and points of perspective may be defined. A structured, logical and methodical approach to secure auditing is mandatory, unless the volume of code is rather small. The intensity and aggressiveness of a secure code audit depends on the risks involved, the scope of the audit based on the cost allowed, and the time allotted for completion. Obviously, a project in excess of 100,000 lines of code is radically different from a 2,000 line project. These and other factors affect the approach to code auditing and the audit timeline.

Secure Code Audit discoveries and feedback may be categorized simply:

• Security Flaws – The primary purpose of a secure code audit is to discover flaws in the programming that may be lead to security exploitations. Security flaws are introduced by programmers who do not understand security, are not educated or experienced with security programming, do not care about security, or wrote the flaws into the programming intentionally. Flaws may include the lack of data cleansing and data validation, lacking encryption, and anything that lets a hacker manipulate the web application or network in an insecure or unexpected fashion. Security flaws may be insidious, in that they may lay dormant and unrecognized in applications and networks awaiting the correct attack, even though the application is intact and fully functional.
• Security Bugs – Code-level problems such as pathway dead-ends, buffer overflows, global variable access, and missing variable handlers constitute security bugs. Bugs are introduced by programmers as a result of insufficient debugging, inept programming capabilities, poor programming and pathway definitions prior to programming, and poor team communication. Programming errors require language-specific mediation with clear understanding of the process being corrected as well as the Big Picture of the entire application.
• Programming Flaws & Bugs – Flaws and bugs that do not constitute a possible security vulnerability, but do negatively affect user interactivity, messaging, and overall application performance are important too.
• Good Programming – Especially in team environments, it is important to note areas of good programming that can be associated with particular programmers. Noting areas of good programming allows the programming team to inspect and evaluate what constitutes “secure” and “quality” programming that should be applied throughout the application.
• Bad Programming – Not so much to pass blame, as to identify the weak programmers and areas requiring attention, bad programming must be mediated for both security flaws as well as bugs. Weak programmers should be educated and some level of oversight should be instated. Areas of bad programming help define a model of what not to do for the programming team.
• Recommendations – Applications may be programmed many different ways, with the same general results. However, there are ideal methods for some processes that may increase performance, provide superior extensibility, and minimize security vulnerabilities during application expansion. “Best Practices” is a relative term, yet all programmers should aspire to improve their programming skills and spectrum of knowledge to produce better code. Recommendations  range greatly from design pathway requirements to memory allocation and performance, to error handling and messaging.

Before launching a secure code audit on a large application with significant volumes of programming, a code base should be compiled and prepared for the auditing team. Auditing code is not typically performed from the user-side, but from the server-side, so every process may be inspected as closely as required. Bugs an flaws may not become apparent from the outside, requiring significant iteration before stumbling upon them. Direct code inspection of a fully operation project allows identification of bugs and flaws and defining what conditions would trigger the flaw or bug.

Code may be evaluated at different levels for categories of issues. The logical approach to methodically reviewing the code provides a structured and controlled approach, so the auditing team does not become overwhelmed or miss issues. Vulnerabilities may be categorized into the overview list below:

Configuration Management: Programming languages utilize a server-side parsing system that handles the code prior to release to the user, and the data submitted by the user to the server. During startup, the server typically reads a configuration file declaring variables, pathways, conditions, and restrictions on the parser. Configuration files can easily create conditions for security vulnerabilities and must be inspected carefully before launching the server and any applications. Default database passwords, session management and storage, and other variables can greatly affect server security. The configuration file controls how errors are handled and what responses are sent out. Debuggging may be disabled for production systems, while kpet enabled for development systems, since debugging messaging may disseminate proprietary or private information about the operating system, the parser conditions, and the application.

Cryptography and Encryption: Protecting data in-transit and between servers is often important, sometimes critical. Credit card information is a well-known issue for the banking and eCommerce communities. Encryption, such as SSL, comes in various flavors and should be defined prior to publication. Defending the privacy of the server’s private certificate is important. Enforcing SSL and encryption on public systems may be desired, if un-encrypted connections are a security risk. Served pages contianing both encrypted and un-encrypted objects may defeat the purpose the encryption as a whole, and requires content handling considerations. Encrypting data goes beyond simple SSL transactions, such as encrypting user passwords and other inforamtion before storing them in a database. Database encryption and decryption methods must be carefully considered and instated prior to publication.

Authentication: Hackers may attack an application using standard web forms and other poits of entry to the server and parser. There are multiple ways to authenticate a user, ranging from very insecure to very secure. Realm protection may generate a nice looking login box that looks secure to general users, but uses simple base64 encryption that any beginner hacker could decrypt in their sleep. Authentication should go beyond the minimum requirements and include session storage of critical data instea dof cookie storage, track IP Addresses and the user fingerprint to prevent attacks such as session hijacking, prevent multiple logins by the same user, limit the duration of the login, etc. Enforcing password updates periodically is healthy. Mandating quality passwords (sometimes user names also) helps minimize attacks such as Brute Force Attacks, such as dictionary or iteration attacks on logins. Note that Brute Force and Iteration Attacks can be somewhat mediated with fingerprinting and throttling restrictions. Blacklisting and IP Filtering may help mediate Denial of Service attacks and other attack methods.

Authorization: Controlling access to restricted and tracked application areas is important and critical. Tracking is important for operations that rely on statistical analysis of traffic to determine future efforts and current goals, etc. Preventing unauthorized access to restricted content is critical, especially for financial applications. eCommerce applications rely on privacy and authorization controls, else face potential dissolution. Most people do not want their credit card information made public or to be abused. Administration access to  inventory management systems, site administration, and user profile management are just a few common aras that require valid authentication mechanisms. Maintinaing authorization control is one of the most critical application issues demanding attention and inspection.

Session Management: TMost websites today use sessions and cookies to track users, traffic, and general data objectives. Session Hijacking is a common security exploitation that renders accounts and profiles vulnerable to the whim of whoever takes control. Restricting session access to the intended admin or user can be critical for protecting proprietary information and user profiles. Especially for the financial communities, losing ctornoll of an acocunt and the funds it manages can be catstrophic not only for the individual, but devastating for the reputation of the business. Session management includes how and where the session is stored, the quality of the session ID generated, maintenance and cleanup mechanisms, and restricting session acces sby tracking IP Addresses and user fingerprints, amongst other unique identifiable user factors.

Data Validation & Data Cleansing: This is a subject any security programmer will revisit over and over… and over and over. Preventing the vast majority of code-level attacks is achieved by validating the data received by the server and cleansing it as needed. Cross Site Scripting, Code and SQL Injection, and other attacks  stop dead in their tracks when the programmer has instatedd quality cleansing and validation of ALL data objects received by users and hackers alike. Everything from character substitution to plain raw code submittedd to the server should be inspected rigorusly with protective measures, error messaging, and administration alerts combined to increase the level of application security and realtime response potential. Identifying SQL Injections as opposed to Buffer Overflows may be a nuance desired by the network administrator, amongst many other filterable attack types. Don’t expect your IDS to do all the work, especially if it resides outside the layer of encryption/decryption!

Exception Management & Error Messaging: There will undoubtedly be a user or attacker who submits garbage to your server, and the response should be handled or meddiated appropriately no matter what was sent. For the general user or site member, error messagin indicates what was wrong with the submitted data, direct them to where the change should be made, and make their navigation and data entry as easy as possible. For the hacker, a friendly and uninformative message that their submission (attack) was rejected increases the chances they will move on and consider other applications more worth their time. The quality and quantity of application programming are directly proportional to the quality and ease of site use for the user. Users who see a blank page when an eror occurs are likely to become frustrated and the application may lose traffic and therefore cash flow.

On the other hand, too much messaging can be a security vulnerability in itself. Server and parser configurations may turn on debugging messaging that reveals far too much arhcitectural information, including code fragments, database query strings, variable names, and other juicy stuff that hackers accumulate during an attack to profile the server and application. Debugging messaging may be turned on at thsw script level, which creates the same vulnerabilities and information disclosure. There is little excuse for sloppiness when taking a development project to a global launch. Differentiating between messaging for programers and that used by visitors is clear and easy to distinguish.

Auditing and Logging: Tracking and logging application use, database connections and queries, errors and exceptions, and attacks can all be performed by even small amounts of code. Attacks can occur in just moments, but after the fact there will be ample time to complain that there was no record of the attack. Without valid logging systems and log analysis systems, applications are often left out in the wind with hope and faith by your side. Unauthorized access and straight forward hacking attacks must be identifiable, traceable, and repeatable in order that they may be remediated and prevented in the future. Although logging is a critical measure to securing your applicatons and network, it must be done logically and with expectation for later analysis. Cluttered logs may be slow to process, but this can be prevented. Logs may be separated into different categories, such as Access, Denial, Error, Attack, Database, or whatever flavor is ideal for your application. Although this is not mandatory for logging systems, it can speed your discovery rate and reduce your headaches. Ample literature on logging system architecture is available Online.

Secure Code Audits may be perrformed by inspecting code for each category above, which is usually slower and less accurate. The other method is to inspect code for each category independently, as this tends to allow a greater focus and has a higher accuracy rate. Audomated code auditing software exists, but few have truly refinde the process performed by the individual expert security programmer. All the same, automated code audits can produce fast results for spot-checking follow-ups by the aditor. There is no reason to reject any single tool, when they may all be combined to perform faster audits, especially on volumous applications. Auditing every line of code is typically not feasible, and in many cases simply ridculous.

The conclusive result of a secure code audit includes a list of what was wrong, where the errors were found, what they imply, and a rating list for the remediators to follow. How to remediate errors is usually a combined effort of the network security consultants performing the security audit, and the application programmers who are intimate with the code. Clever “fixes” and temporary “patches” are not a substitute for solid, viable programming, unless your project is for Microsoft. Security Policies and Programming Policies may be developed during the auditing and remediation efforst, setting a new pace for more secure and quality programming. Educating and managing the programming team may be a valid direction to take, depending on the audit results. As useful and powerful as a secure code audit may be, the steps taken subsequently should not defunct the efforts of the audit by introducing new insecure code! Whatever the results and future requirements, the single goal for all involve must be the greater benefit of the application, to increase code and network security and protect the business.

A secure code audit by an experienced security programming expert is the only thorough and effective way to discover security issues in an application. Auditing should be scheduled as part of the whole development process, including smaller audits on sections of code with more changes than others, or written by less security-minded programmers. Code inspection constitutes the most viable security measure for preventing and remedating flaws prior to launch and during development.

Simply answered, “Do I need a secure code audit” is a decision you make based on the quality of your programming team’s knowledge of security, and how important it is that your applications and network not be successfully attacked.

If you have questions about secure code audits and improving your programing team’s understanding of programming security, contact me with your questions and concerns. andrewlandsman at emagined dot com

Web forms are a big security issue for any website, especially if the website framework was not developed with security programming in mind. The major purpose of a web form is to allow a visitor to submit information to your web server for processing of some sort. Simple programming would assume the visitor would enter data into the form fields as expected and desired, and all would be processed without a hitch. Unfortunately, hackers and malicious users do not always submit the expected or desired field data. A malicious user may want to submit rude or useless jibberish just to waste everyone’s time. FormBots will submit advertising for Viagra or reduced mortgage rates, hoping that somewhere an admin will rush to buy… who responds to spam anyway? On the more extreme end of the scope, hackers will submit more than simple jibberish.

When a hacker discovers a form that was not programmed with security in mind, the wheels of misdeed start to speed. The goal of a hacker is to discover paths of entry into your applications and into your network. Gaining control over the server is a major goal, while causing modifications to the server or database are still quality goals. The hacker will start by testing the waters to see what the server is doing with the data and how rejections or mis-processing results. This leads us down the path of how hackers work, which is not entirely within the scope of this article. Our focus here is whether the web form in a site is vulnerable or not.

Lets use the newsletter signup form as an example. The form has a single field and a single button. The web programmer designed the email address field to allow only up to 125 characters and used Javascript to check the format of the data entered before it can be submitted to the web server. As fancy ass that sounds, using Javascript and user-end restrictions is essentially useless in the battle against being hacked. They provide some gudance to the user and perhaps release some burden of processing from the web server, yet in terms of security can be ignored as such. A hacker can bypasss these altogether, and in most cases can submit the data without using the web form, web page, or web site at all! hackers can POST or GET form data to your server directly with some serious repetition and automation, sensing thousands of submissions, each trying new variations on the data submitted.

Setting any Javascript or web page programming, we must turn to the server-side processing for real security measures, in the scope of the web server and the chosen processing language (PHP, ASP, CFM…). An experienced security programmer thinsk in terms of what can go wrong more than what can go right. What if No Data is submitted and the email address variable is empty? What if the data submitted is a web address instead of an email address? Holy Cow, what if the user submits an SQL Injection targeting the database to extract all our records or even delete every record? These are good questions for the programmer to consider when creating the web form in the first place, not later when the owner freaks out and asks, “Where did the 63,756 email address records all disappear to?”

If your web programmer cannot define the strict measures for protecting your server against form attacks, you must inspect your code, evaluate your entire site, and make sure you are not a target for attack. With multiple programmers on a team, you may find one form on the left is secure, but the form over on the righ tis completely insecure. You only need one hole in your boat to sink the entire crew. Lets review some major methods of attack and the two major programming requirements to prevent them.

Attacks come in a few general flavors with specific intentions:

• Low Threats – Idiots or malicious users submit garbage data.
• Medium Threats – Idiots or FormBots submit advertising or large volumes of submissions to cloud your records.
• High Threats – Hackers submit SQL Injections or Code Injections while trying to gain control of your server or applications.

There are two major methods for preventing these and other attacks, plus optional methods:

• Data Cleansing – Remove/replace undesired/illegal characters or strings form the submitted data.
• Data Validation -Inspect the data to assure it meets satisfactory requirement for the variable type expected.
• Data Testing – In some cases, the data may be tested to determine if it is truly useful data.

Data Validation can save you a lot of headaches from the Low to Medium threats, as well as the High Threats. If the data expected is supposed to be an email address, it should look like an email address, nothing else. There are many ways to paint this picture, but the essential approach is the same. If the value does not meet “email address criteria” it is simply not valid. Regular expression filtering will match the submitted value against a pattern meeting email address format specifications, and provide the best filtering possible. On the simplistic end, an email address should contain a single @ symbol, and at least one period, etc.Hackers can get past simple filtering and use of regular expression filters is advised.

Data Cleansing is most effective when combined with Data Validation, but can in itself prevent a significant percentage of attacks. An email address should not contain various illegal characters, which may be perceived by your parser (your programming language’s server-side evaluator) as code rather than form data. If you find illegal or unexpected characters in the submittedd data, you can remove or replace the characters, or simply reject the entire form. Data Cleansing and Validation are your best defense against web form attacks and there is both an artistic and scientific approach to usage.

Now, lets say the user is malicious and wants to submit the same email address a zillion times. Your application should inspect previously submitted email addresses and reject the addition as a repeat. But what happens when the attacker uses an automated attack that increments or iterates the alphabet submitting endless numbers of correctly formatted, but non-existent, email addresses? Your server should throttle the number of submissions allowed from any single IP Address to start, which mut be a server-side restriction rather than using cookies/sessions to manage the throttling. You may at this point opt to include Data Testing to make sure the address really exists.

Data Testing is less frequently applied in web applications, but the email address data type is one that may mandate its use. The server first cleanses and validates the address. Given that the address has a valid format, the application continues and parses the address into the doain portion and the name portion. A simple MX Record lookup will list the possible Mail Exchange DNS Records fgor the parsed domain portion, and if they exist, the application moves on the the next test. DNS records may be faked, so the application should attempt to connect to the Mail Exchange Servers, in sequence, to see if any of them respond. If any of the Mail Echange servers respond, the application moves on, and using the entire address, the application asks the Mail Exchange server if it would be willing to receive email for the name portion of the address. If the Mail Exchange server accepts the email, it is likely a valid address, but if it is rejected, the address is surely invalid. The reason the address may still be invalid despite being accepted by the Mail Exchange server is because it may be configured to accept ALL emails and deliver the invalid addresses to the Postmaster or server admin.

The process of testing an email address described above is simplistic for reading. Programming this as a security feature is not as easy as describing it, but still not difficult for the security programmer. This is only to screen and test an email addres, where there are many data types and formats you must test for. EVERY SINGLE FIELD of a form is a possible port of entry for a hacker, and thay must EACH AND EVERY ONE be filtered. Iterative loops may filter same data types, such as last name, first name, middle name. But different data types should be handled separately for the best network security results.

With various methods for attacking a web form, and the serious need for web application security for your network, knowing that security programming was part of your project has become mandatory. If you are about to start a project, make sure you have at least one security programmer in the programming team. If your project is underway, and you lack security programmers, be prepared to start a Secure Code Audit upon completion with possible re-programming if errors are found. The same Secure Code Audit is necessary if your project has already been launched and nobody assured secure programming in the design. Beware “Programming Frameworks” that give a misleading sense of capability and efficiency to faux-programmers. Franmeworks are constructed by other programmers who may not be as security-minded as you need, and introduce security vulnerabilities that are easily overlooked. There is no true substitute for an experienced security programmer proving the safety of your web applications and network!

Bear in mind that a radio, checkmark, dropMenu or List field object may easily be converted to any other field object type by a hacker. Form objects that appear to only allow a Yes/No submission are still major points of attack, while deceiving programmers who are not security-minded. A majority of programmers overlook the intricacies of security programming while maintaining a stance of being security-minded in their programming. The litmus test for their products is generated by scanning their applications with vulnerability scanners and doing  independent secure code audits.

To be more specific, the question is really whether they are “Ethical Hackers” who can create and manage applications and systems with security in mind, to enforce security measures and keep your business safe. “Hackers” get a bad wrap due to Black Hat hackers who cause problems, and some Gray Hat hackers who cause problems regardless of their intentions, or lack thereof. White Hat hackers and Ethical Hackers are the good guys, but are less likely to announce their skill set in a general meeting because of the stereoyped lashback. From my own experiences, being brought into development projects, clients typically get scared to learn that I am a “hacker,” unless that was the reason I was brought in.

So, you ask yourself, “Why would I want a hacker on my team?” Well, to help defend you against the bad guys! Finding good programmers is easy, but finding good programmers who are aware of Network Security and who can defend your business against the bad guys is not so easy. Those programmers who are unaware of true network security are a massive liability to the projects, systems, and the entire business. A huge number of security exploitations arise from security vulnerabilities introduced by unaware programmers. Without a working expertise as an Ethical Hacker, a programmer can bring your entire operation to its knees with no clue how much damage was done.

Setting the stigma aside of what a “hacker” is, it is an experienced hacker who makes the best programmer and network administrator. With every push of an electron, the security minded team member will remain paranoid and instate security measures in every point of entry or potential security vulnerability. While your project evolves and incurs deviation from original expectations with extensibility, the security minded developer keeps an eye out for issues and can test the applications and systems for possible vulnerabilties. Even moreso important is that team member’s ability to test each potential vulnerability as effectively as a Bad hacker would, to groom that vulnerability into a security exploitation.

Beware the caveats of the answers you may receive from team members. For some people, the title of “Hacker” is glorified and sought after. The real hacker on your team may abstain from answering, and be your best team member for acting as your network security consultant. The faux-hacker may speak up, but know little more than simple cleansing and validation, but miss the critical measures that eventually bring down your business as a result blissful ignorance.

Now you ask yourself, “How do I know if the guy who speaks up is really a skilled hacker, and is he a White Hat?” This is a tough question to answer, especially for business directors who do not focus their attention on network security. Of course, you want to know how long the individual has worked for your company. Has the individual excelled beyond default expectations? Have there been significant contribution to reach your goals more effectively or efficiently? Hopefully the individual can identify any lacking skills and act as a company or project liaison with a network security consultancy like Emagined Security. Send your “hacker” to classes and seminars to help develop the skills your business needs to gain a security advantage.

“Ay carumba, nobody on my team understands security! Am I in trouble?” Heck no, you have options. The first thing you can do is contact Emagined Security for expert network security consultation. Security for your network and programming is no lax issue… mediate as quickly as possible. Security vulnerabilities are like ticking time bombs with unknown times for catastrophic exploitation. Emagined Security can help you resolve your internal resources and guide your business to a clear path of discovery and remediation. From secure code auditing to internal and external penetration testing, your applications and systems must survive comprehensive security testing and analysis, equal to or in excess of what bad hackers would deliver.

With an expert team of network security professionals giving you answers and protecting your business, you will not only be able to answer the tough security-minded questions, you’ll know what questions need to be asked. It is true that an ounce of prevention is worth a pound of cure. Don’t wait until you are attacked or invaded to jump into action. There is no moment in time as valid and powerful for finding resolution as the current moment in time. In this world of seemingly impending doom, you should seek a security stance that truly lets you sleep at night and focus on forward momentum for your business.

Introduction
With more and more personal information — such as credit card information, maiden names, passwords, etc. — being stored on the web, any developer(especially a PHP developer) cannot afford to be lax about application security. The most secure website is one that does not have any PHP or CGI or even HTML. But then it would not be a website at all, would it

The battle for supremacy in web application security is not between hackers and programmers; it is between what you want your web application to do and whether it is safe for it to carry out those tasks. It is always better for a developer to start any project with the knowledge that any application that he  creates will only be as safe as he makes it. It is for this reason that every developer should ensure that he or she stays informed about the latest security threats and to look for possible solutions for these threats if at all possible.

A security plan
When starting a new project a PHP programmer must think of security from the word go. Think of security first, last and in between. Security is abstract in any language, unlike language features such as conditional expressions or loops or any of the other characteristics. Security in a scripting language such as PHP is more developer dependent than language dependent. In other words, although the language offers you the tools to create secure code, it cannot prevent insecure code.

Thus, the degree to which code is secure almost entirely depends on how security conscious and well informed its developer is. If you have developed web applications before, then you will know that nothing is really one hundred percent secure. So everything boils down to three points when developing an application:

• Identify the needs and potential weaknesses of an application from the word go.
• Try as much as possible to deal with those weaknesses when programming.
• Always have a backup plan for when things go pear shaped. And believe me, things do go wrong!

Not all is doom and gloom on the security front. If you know a particular language well, then you will be able to write very secure code that will enable you to sleep well at night, instead of worrying about the new attacks and techniques that are constantly being thrown at web applications. So what does PHP offer in this regard and what can we do to make our applications more secure? There are things that we can do to make our PHP installation more secure. The first thing we need to do is look at the installation itself. In the coming sections we will cover the following:

• Register Globals
• Error reporting
• Code Exposure

There are quite a few other features available that we can look at, but for the sake of brevity we will focus on the above topics because I think these are among the most important ones.

Is your PHP Installation Secure?
The first thing you should check is your Register Globals. They have to be turned off for security reasons. All PHP developers should know this and make sure that it is the case in their PHP installations. There are two main reasons why this is necessary:

• If Register Globals are not turned off, they can increase the magnitude of a security vulnerability.
• Turning Register Globals on hides the origin of data, conflicting with a developer’s responsibility to keep track of data at all times.
• So what happens if the register globals are not turned off? Two things happen:
• It takes care of the complexity of parsing raw form data. This makes working with form data considerably easier for the developer, but at the expense of control.
• Global variables are created from numerous remote sources. This makes tracking variables very difficult, and from a security point of view this is a huge risk.

It is worth pointing out that register globals on their own do not necessarily create a security vulnerability; the vulnerability usually comes as a result of the developer making a mistake. You should still ensure that your register globals are turned off for both security reasons and also for portability issues. Most production environments will have their register globals turned off, and if your applications were created with register globals turned on, they will be unusable in those environments.

On a precautionary note, if you develop applications that you think will be deployed in an environment where register_globals are enabled, then make sure that you initialize all variables and set error reporting to E_ALL or E_STRICT. This is to alert yourself to the use of uninitialized variables, as any use of uninitialized variables is almost always a security risk when register_globals are turned on. So where do you turn off register globals? Simply open up your PHP ini file and set register globals to off. Below is an extract from my PHP configuration file with register globals set to off:

• You should do your best to write your scripts so that they do not require
• register_globals to be on; Using form variables as globals can easily lead
• to possible security problems, if the code is not very well thought of.

register_globals = Off

Error Reporting
Another area in which security vulnerabilities are common is error reporting. Every developer makes mistakes, and while most mistakes are harmless, some can also be a security risk. So, in the interest of writing efficient, and risk free code, I would suggest that error reporting be turned on. This is particularly useful at the development stage of a project and will enable you to effectively debug code before deploying it.

PHP provides detailed information, and this information can be a security risk. So it is important to hide this information from the public. You can simply do it by setting display_errors to off. Below is an extract of my PHP configuration file(php.ini) showing display errors set to off:

display_errors = Off [Security]

ini_set(’display_errors’,’off’);
ini_set(’display_errors’,0);

With this directive set to off, errors that occur during the execution of scripts will no longer be displayed as a part of the script output, and thus, will no longer be exposed to remote users. With some errors, the error message content may expose information about your script, web server, or database server that may be exploitable for hacking. Production sites should have this directive set to off.

But how will you be able to see what errors are in your code? Well, the safest way would be to make PHP write those errors to a log. You do this by setting log_errors to on and indicate the location of the log with error_log. Because the level of error reporting can cause some errors to be hidden, you should turn up PHP’s default error_reporting setting to at least E_ALL ( E_ALL | E_STRICT is the highest setting, offering suggestions for forward compatibility, such as deprecation notices).

PHP error reporting is such that all error-reporting behavior can be modified at any level, so if you are on a shared host or are otherwise unable to make changes to files such as php.ini, httpd.conf, or . htaccess, you can implement these recommendations with code similar to the following:

<?php
ini_set(’error_reporting’, E_ALL | E_STRICT);
ini_set(’display_errors’, ‘Off’);
ini_set(’log_errors’, ‘On’);
ini_set(’error_log’, ‘/usr/local/apache/logs/error_log’);
?>

Another feature of PHP error reporting is that it allows you to handle your own errors, with the set_error_handler() function:

<?php
set_error_handler(”my error handler”);
?>

This allows you to define your own function ( my_error_handler( ) ) to handle errors; the following is an example implementation:

<?php
function my_error_handler($number, $string, $file, $line, $context)
{
$error = “= == == == ==nPHP ERRORn= == == == ==n”;
$error .= “Number: [$number]n”;
$error .= “String: [$string]n”;
$error .= “File: [$file]n”;
$error .= “Line: [$line]n”;
$error .= “Context:n” . print_r($context, TRUE) . “nn”;

error_log($error, 3, ‘/usr/local/apache/logs/error_log’);
}
?>

Data Exposure
Finally, let’s take a brief look at another area of security risks: data exposure. This is a common security risk, especially when it comes to SQL queries. When it comes to retrieving data from a database, you should only retrieve the information that you require. This way you minimize the risk of data being exposed unnecessarily. For example:

$query = “SELECT name,surname from usertable WHERE name=”‘.$_POST[’uname’].”‘ AND surname=’”.$_POST[’usurname’].”‘”;

The above query only exposes two fields of the database and actually only retrieves data that is required as opposed to the query below that exposes a lot more data:

$query = “SELECT * from usertable WHERE name=”‘.$_POST[’uname’].”‘ AND surname=’”.$_POST[’usurname’].”‘”;

The second query actually retrieves a lot more data than is required. Thus the risk of data exposure is higher.