( ';')< "ЦΓΤІШΛΤΞ ΠΛΡΣΤЯ"

Wednesday, October 19, 2011

NT Security

The Logon Process

WinLogon

Users must log on to a Windows NT machine in order to use that NT based machine or network. The logon process itself cannot be bypassed, it is mandatory. Once the user has logged on, an access token is created (this token will be discussed in more detail later). This token contains user specific security information, such as: security identifier, group identifiers, user rights and permissions. The user, as well as all processes spawned by the user are identified to the system with this token.

The first step in the WinLogon process is something we are all familiar with, CTRL+ALT+DEL. This is NT's default Security Attention Sequence (SAS - The SAS key combo can be changed. We will also discuss that later.). This SAS is a signal to the operating system that someone is trying to logon. After the SAS is triggered, all user mode applications pause until the security operation completes or is cancelled. (Note: The SAS is not just a logon operation, this same key combination can be used for logging on, logging off, changing a password or locking the workstation.) The pausing, or closing, of all user mode applications during SAS is a security feature that most people take for granted and dont understand. Due to this pausing of applications, logon related trojan viruses are stopped, keyloggers (programs that run in memory, keeping track of keystrokes, therefor recording someones password) are stopped as well.

The user name is not case sensitive but the password is.

After typing in your information and clicking OK (or pressing enter), the WinLogon process supplies the information to the security subsystem, which in turn compares the information to the Security Accounts Manager (SAM). If the information is compliant with the information in the SAM, an access token is created for the user. The WinLogon takes the access token and passes it onto the Win32 subsytem, which in turn starts the operating systems shell. The shell, as well as all other spawned processes will receive a token. This token is not only used for security, but also allows NTs auditing and logging features to track user usage and access of network resources.

Note: All of the logon components are located in a file known as the Graphical Indetification and Authentication (GINA) module, specifically MSGINA.DLL. Under certain conditions, this file can be replaced, which is how you would change the SAS key combination.

For fine tuning of the WinLogon process, you can refer to the registry. All of the options for the WinLogon process are contained in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon area. You can also fine tune the process by using the Policy Editor.

Logging on to a Domain

If an NT machine is a participant on a Domain, you would not only need to login to the local machine, but the Domain as well. If a computer is a member of a Domain, the WinLogon process is replaced by the NetLogon process.

Security Architecture Components

Local Security Authority (LSA): Also known as the security subsystem, it is the central portion of NT security. It handles local security policies and user authentication. The LSA also handles generating and logging audit messages.

Security Accounts Manager (SAM): The SAM handles user and group accounts, and provides user authentication for the LSA.

Security Reference Monitor (SRM): The SRM is in charge of enforcing and assuring access validation and auditing for the LSA. It references user account information as the user attempts to access resources.

Introduction to Securing an NT Box

Abstract

Microsoft Windows NT operating system provides several security features. However, the default out-of-the-box configuration is highly relaxed, especially on the Workstation product. This is because the operating system is sold as a shrink-wrapped product with an assumption that an average customer may not want to worry about a highly restrained but secure system on their desktop.

A particular installation's requirements can differ significantly from another. Therefore, it is necessary for individual customers to evaluate their particular environment and requirements before implementing a security configuration. This is also because implementing security settings can impact system configuration. Certain applications installed on Windows NT may require more relaxed settings to function properly than others because of the nature of the product. Customers are therefore advised to careful evaluate recommendations in the context of their system configurations and usage.

If you install a Windows NT machine as a web server or a firewall, you should tighten up the security on that box. Ordinary machines on your internal network are less accessible than a machine the Internet. A machine accessible from the Internet is more vulnerable and likely to be attacked. Securing the machine gives you a bastion host. Some of the things you should do include:

* Remove all protocol stacks except TCP/IP, since IP is the only protocol that runs on the Internet

* Remove unnecessary network bindings

* Disable all unnecessary accounts, like guest

* Remove share permissions and default shares

* Remove network access for everyone (User Manger -> Policies ->User rights, "Access this computer from the network")

* Disable unnecessary services

* Enable audit logging

* Track the audit information

Physical Security Considerations

Take the precautions you would with any piece of valuable equipment to protect against casual theft. This step can include locking the room the computer is in when no one is there to keep an eye on it, or using a locked cable to attach the unit to a wall. You might also want to establish procedures for moving or repairing the computer so that the computer or its components cannot be taken under false pretenses.

Use a surge protector or power conditioner to protect the computer and its peripherals from power spikes. Also, perform regular disk scans and defragmentation to isolate bad sectors and to maintain the highest possible disk performance.

As with minimal security, the computer should be protected as any valuable equipment would be. Generally, this involves keeping the computer in a building that is locked to unauthorized users, as most homes and offices are. In some instances you might want to use a cable and lock to secure the computer to its location. If the computer has a physical lock, you can lock it and keep the key in a safe place for additional security. However, if the key is lost or inaccessible, an authorized user might be unable to work on the computer.

You might choose to keep unauthorized users away from the power or reset switches on the computer, particularly if your computer's rights policy denies them the right to shut down the computer. The most secure computers (other than those in locked and guarded rooms) expose only the computer's keyboard, monitor, mouse, and (when appropriate) printer to users. The CPU and removable media drives can be locked away where only specifically authorized personnel can access them.

Backups

Regular backups protect your data from hardware failures and honest mistakes, as well as from viruses and other malicious mischief. The Windows NT Backup utility is described in Chapter 6, "Backing Up and Restoring Network Files" in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Help.

Obviously, files must be read to be backed up, and they must be written to be restored. Backup privileges should be limited to administrators and backup operators-people to whom you are comfortable giving read and write access on all files.

Networks and Security

If the network is entirely contained in a secure building, the risk of unauthorized taps is minimized or eliminated. If the cabling must pass through unsecured areas, use optical fiber links rather than twisted pair to foil attempts to tap the wire and collect transmitted data.

Restricting the Boot Process

Most personal computers today can start a number of different operating systems. For example, even if you normally start Windows NT from the C: drive, someone could select another version of Windows on another drive, including a floppy drive or CD-ROM drive. If this happens, security precautions you have taken within your normal version of Windows NT might be circumvented.

In general, you should install only those operating systems that you want to be used on the computer you are setting up. For a highly secure system, this will probably mean installing one version of Windows NT. However, you must still protect the CPU physically to ensure that no other operating system is loaded. Depending on your circumstances, you might choose to remove the floppy drive or drives. In some computers you can disable booting from the floppy drive by setting switches or jumpers inside the CPU. If you use hardware settings to disable booting from the floppy drive, you might want to lock the computer case (if possible) or lock the machine in a cabinet with a hole in the front to provide access to the floppy drive. If the CPU is in a locked area away from the keyboard and monitor, drives cannot be added or hardware settings changed for the purpose of starting from another operating system. Another simple setting is to edit the boot.ini file such that the boot timeout is 0 seconds; this will make hard for the user to boot to another system if one exists.

On many hardware platforms, the system can be protected using a power-on password. A power-on password prevents unauthorized personnel from starting an operating system other than Windows NT, which would compromise system security. Power-on passwords are a function of the computer hardware, not the operating system software. Therefore the procedure for setting up the power-on password depends on the type of computer and is available in the vendor's documentation supplied with the system.

NT Security

The user name is not case sensitive but the password is.

Thursday, August 18, 2011

Top 25 Most Dangerous Programming Mistakes

Improper Input Validation
Ensure that your input is valid. If you're expecting a number, it shouldn't contain letters. Nor should the price of a new car be allowed to be a dollar. Incorrect input validation can lead to vulnerabilities when attackers can modify their inputs in unexpected ways. Many of today's most common vulnerabilities can be eliminated, or at least reduced, with strict input validation.
Improper Encoding or Escaping of Output
Insufficient output encoding is at the root of most injection-based attacks. An attacker can modify the commands that you intend to send to other components, possibly leading to a complete compromise of your application - not to mention exposing the other components to exploits that the attacker would not be able to launch directly. When your program generates outputs to other components in the form of structured messages such as queries or requests, be sure to separate control information and metadata from the actual data.
Failure to Preserve SQL Query Structure (aka 'SQL Injection')
If attackers can influence the SQL that you send to your database, they can modify the queries to steal, corrupt, or otherwise change your underlying data. If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security.
Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
Cross-site scripting (XSS) is a result of combining the stateless nature of HTTP, the mixture of data and script in HTML, lots of data passing between web sites, diverse encoding schemes, and feature-rich web browsers. If you're not careful, attackers can inject Javascript or other browser-executable content into a web page that your application generates. Your web page is then accessed by other users, whose browsers execute that malicious script as if it came from you -- because, after all, it did come from you! Suddenly, your web site is serving code that you didn't write. The attacker can use a variety of techniques to get the input directly into your server, or use an unwitting victim as the middle man.
Failure to Preserve OS Command Structure (aka 'OS Command Injection')
Your software acts as a bridge between an outsider on the network and the internals of your operating system. When you invoke another program on the operating system, and you allow untrusted inputs to be fed into the command string, you are inviting attackers into your operating system.
Cleartext Transmission of Sensitive Information
Information sent across a network crosses many different nodes in transit to its final destination. If your software sends sensitive, private data or authentication credentials, beware: attackers could sniff them right off the wire. All they need to do is control one node along the path to the final destination, any node within the same networks of those transit nodes, or plug into an available interface. Obfuscating traffic using schemes like Base64 and URL encoding offers no protection.
Cross-Site Request Forgery (CSRF)
Cross-site request forgery is like accepting a package from a stranger -- except the attacker tricks a user into activating a HTTP request "package" that goes to your site. The user might not even be aware that the request is being sent, but once the request gets to your server, it looks as if it came from the user -- not the attacker. The attacker has masqueraded as a legitimate user and gained all the potential access that the user has. This is especially handy when the user has administrator privileges, resulting in a complete compromise of your application's functionality.
Race Condition
A race condition involves multiple processes in which the attacker has full control over one process; the attacker exploits the process to create chaos, collisions, or errors. Data corruption and denial of service are the norm. The impact can be local or global, depending on what the race condition affects - such as state variables or security logic - and whether it occurs within multiple threads, processes, or systems.
Error Message Information Leak
Chatty error messages can disclose secrets to any attacker who misuses your software. The secrets could cover a wide range of valuable data, including personally identifiable information (PII), authentication credentials, and server configuration. They might seem like harmless secrets useful to your users and admins, such as the full installation path of your software -- but even these little secrets can greatly simplify a more concerted attack.
Failure to Constrain Operations within the Bounds of a Memory Buffer
The scourge of C applications for decades, buffer overflows have been remarkably resistant to elimination. Attack and detection techniques continue to improve, and today's buffer overflow variants aren't always obvious at first or even second glance. You may think that you're completely immune to buffer overflows because you write your code in higher-level languages instead of C. But what is your favorite "safe" language's interpreter written in? What about the native code you call? What languages are the operating system API's written in? How about the software that runs Internet infrastructure?
External Control of Critical State Data
If you store user state data in a place where an attacker can modify it, this reduces the overhead for a successful compromise. Data could be stored in configuration files, profiles, cookies, hidden form fields, environment variables, registry keys, or other locations, all of which can be modified by an attacker. In stateless protocols such as HTTP, some form of user state information must be captured in each request, so it is exposed to an attacker out of necessity. If you perform any security-critical operations based on this data (such as stating that the user is an administrator), then you can bet that somebody will modify the data in order to trick your application.
External Control of File Name or Path
When you use an outsider's input while constructing a filename, the resulting path could point outside of the intended directory. An attacker could combine multiple ".." or similar sequences to cause the operating system to navigate out of the restricted directory. Other file-related attacks are simplified by external control of a filename, such as symbolic link following, which causes your application to read or modify files that the attacker can't access directly. The same applies if your program is running with raised privileges and it accepts filenames as input. Similar rules apply to URLs and allowing an outsider to specify arbitrary URLs.
Untrusted Search Path
Your software depends on you, or its environment, to provide a search path (or working path) to find critical resources like code libraries or configuration files. If the search path is under attacker control, then the attacker can modify it to point to resources of the attacker's choosing.
Failure to Control Generation of Code (aka 'Code Injection')
While it's tough to deny the sexiness of dynamically-generated code, attackers find it equally appealing. It becomes a serious vulnerability when your code is directly callable by unauthorized parties, if external inputs can affect which code gets executed, or if those inputs are fed directly into the code itself.
Download of Code Without Integrity Check
If you download code and execute it, you're trusting that the source of that code isn't malicious. But attackers can modify that code before it reaches you. They can hack the download site, impersonate it with DNS spoofing or cache poisoning, convince the system to redirect to a different site, or even modify the code in transit as it crosses the network. This scenario even applies to cases in which your own product downloads and installs updates.
Improper Resource Shutdown or Release
When your system resources have reached their end-of-life, you dispose of them: memory, files, cookies, data structures, sessions, communication pipes, and so on. Attackers can exploit improper shutdown to maintain control over those resources well after you thought you got rid of them. Attackers may sift through the disposted items, looking for sensitive data. They could also potentially reuse those resources.
Improper Initialization
If you don't properly initialize your data and variables, an attacker might be able to do the initialization for you, or extract sensitive information that remains from previous sessions. If those variables are used in security-critical operations, such as making an authentication decision, they could be modified to bypass your security. This is most prevalent in obscure errors or conditions that cause your code to inadvertently skip initialization.
Incorrect Calculation
When attackers have control over inputs to numeric calculations, math errors can have security consequences. It might cause you to allocate far more resources than you intended - or far fewer. It could violate business logic (a calculation that produces a negative price), or cause denial of service (a divide-by-zero that triggers a program crash).
Improper Access Control (Authorization)
If you don't ensure that your software's users are only doing what they're allowed to, then attackers will try to exploit your improper authorization and exercise that unauthorized functionality.
Use of a Broken or Risky Cryptographic Algorithm
Grow-your-own cryptography is a welcome sight to attackers. Cryptography is hard. If brilliant mathematicians and computer scientists worldwide can't get it right -- and they're regularly obsoleting their own techniques -- then neither can you.
Hard-Coded Password
Hard-coding a secret account and password into your software is extremely convenient -- for skilled reverse engineers. If the password is the same across all your software, then every customer becomes vulnerable when that password inevitably becomes known. And because it's hard-coded, it's a huge pain to fix.
Insecure Permission Assignment for Critical Resource
Beware critical programs, data stores, or configuration files with default world-readable permissions. While this issue might not be considered during implementation or design, it should be. Don't require your customers to secure your software for you! Try to be secure by default, out of the box.
Use of Insufficiently Random Values
You may depend on randomness without even knowing it, such as when generating session IDs or temporary filenames. Pseudo-Random Number Generators (PRNG) are commonly used, but a variety of things can go wrong. Once an attacker can determine which algorithm is being used, he can guess the next random number often enough to launch a successful attack after a relatively small number of tries.
Execution with Unnecessary Privileges
Your software may need special privileges to perform certain operations; wielding those privileges longer than necessary is risky. When running with extra privileges, your application has access to resources that the application's user can't directly reach. Whenever you launch a separate program with elevated privileges, attackers can potentially exploit those privileges.
Client-Side Enforcement of Server-Side Security
Don't trust the client to perform security checks on behalf of your server. Attackers can reverse engineer your client and write their own custom clients. The consequences will vary depending on what your security checks are protecting, but some of the more common targets are authentication, authorization, and input validation.

Top 25 Most Dangerous Programming Mistakes

Improper Input Validation
Ensure that your input is valid. If you're expecting a number, it shouldn't contain letters. Nor should the price of a new car be allowed to be a dollar. Incorrect input validation can lead to vulnerabilities when attackers can modify their inputs in unexpected ways. Many of today's most common vulnerabilities can be eliminated, or at least reduced, with strict input validation.
Improper Encoding or Escaping of Output
Insufficient output encoding is at the root of most injection-based attacks. An attacker can modify the commands that you intend to send to other components, possibly leading to a complete compromise of your application - not to mention exposing the other components to exploits that the attacker would not be able to launch directly. When your program generates outputs to other components in the form of structured messages such as queries or requests, be sure to separate control information and metadata from the actual data.
Failure to Preserve SQL Query Structure (aka 'SQL Injection')
If attackers can influence the SQL that you send to your database, they can modify the queries to steal, corrupt, or otherwise change your underlying data. If you use SQL queries in security controls such as authentication, attackers could alter the logic of those queries to bypass security.
Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
Cross-site scripting (XSS) is a result of combining the stateless nature of HTTP, the mixture of data and script in HTML, lots of data passing between web sites, diverse encoding schemes, and feature-rich web browsers. If you're not careful, attackers can inject Javascript or other browser-executable content into a web page that your application generates. Your web page is then accessed by other users, whose browsers execute that malicious script as if it came from you -- because, after all, it did come from you! Suddenly, your web site is serving code that you didn't write. The attacker can use a variety of techniques to get the input directly into your server, or use an unwitting victim as the middle man.
Failure to Preserve OS Command Structure (aka 'OS Command Injection')
Your software acts as a bridge between an outsider on the network and the internals of your operating system. When you invoke another program on the operating system, and you allow untrusted inputs to be fed into the command string, you are inviting attackers into your operating system.
Cleartext Transmission of Sensitive Information
Information sent across a network crosses many different nodes in transit to its final destination. If your software sends sensitive, private data or authentication credentials, beware: attackers could sniff them right off the wire. All they need to do is control one node along the path to the final destination, any node within the same networks of those transit nodes, or plug into an available interface. Obfuscating traffic using schemes like Base64 and URL encoding offers no protection.
Cross-Site Request Forgery (CSRF)
Cross-site request forgery is like accepting a package from a stranger -- except the attacker tricks a user into activating a HTTP request "package" that goes to your site. The user might not even be aware that the request is being sent, but once the request gets to your server, it looks as if it came from the user -- not the attacker. The attacker has masqueraded as a legitimate user and gained all the potential access that the user has. This is especially handy when the user has administrator privileges, resulting in a complete compromise of your application's functionality.
Race Condition
A race condition involves multiple processes in which the attacker has full control over one process; the attacker exploits the process to create chaos, collisions, or errors. Data corruption and denial of service are the norm. The impact can be local or global, depending on what the race condition affects - such as state variables or security logic - and whether it occurs within multiple threads, processes, or systems.
Error Message Information Leak
Chatty error messages can disclose secrets to any attacker who misuses your software. The secrets could cover a wide range of valuable data, including personally identifiable information (PII), authentication credentials, and server configuration. They might seem like harmless secrets useful to your users and admins, such as the full installation path of your software -- but even these little secrets can greatly simplify a more concerted attack.
Failure to Constrain Operations within the Bounds of a Memory Buffer
The scourge of C applications for decades, buffer overflows have been remarkably resistant to elimination. Attack and detection techniques continue to improve, and today's buffer overflow variants aren't always obvious at first or even second glance. You may think that you're completely immune to buffer overflows because you write your code in higher-level languages instead of C. But what is your favorite "safe" language's interpreter written in? What about the native code you call? What languages are the operating system API's written in? How about the software that runs Internet infrastructure?
External Control of Critical State Data
If you store user state data in a place where an attacker can modify it, this reduces the overhead for a successful compromise. Data could be stored in configuration files, profiles, cookies, hidden form fields, environment variables, registry keys, or other locations, all of which can be modified by an attacker. In stateless protocols such as HTTP, some form of user state information must be captured in each request, so it is exposed to an attacker out of necessity. If you perform any security-critical operations based on this data (such as stating that the user is an administrator), then you can bet that somebody will modify the data in order to trick your application.
External Control of File Name or Path
When you use an outsider's input while constructing a filename, the resulting path could point outside of the intended directory. An attacker could combine multiple ".." or similar sequences to cause the operating system to navigate out of the restricted directory. Other file-related attacks are simplified by external control of a filename, such as symbolic link following, which causes your application to read or modify files that the attacker can't access directly. The same applies if your program is running with raised privileges and it accepts filenames as input. Similar rules apply to URLs and allowing an outsider to specify arbitrary URLs.
Untrusted Search Path
Your software depends on you, or its environment, to provide a search path (or working path) to find critical resources like code libraries or configuration files. If the search path is under attacker control, then the attacker can modify it to point to resources of the attacker's choosing.
Failure to Control Generation of Code (aka 'Code Injection')
While it's tough to deny the sexiness of dynamically-generated code, attackers find it equally appealing. It becomes a serious vulnerability when your code is directly callable by unauthorized parties, if external inputs can affect which code gets executed, or if those inputs are fed directly into the code itself.
Download of Code Without Integrity Check
If you download code and execute it, you're trusting that the source of that code isn't malicious. But attackers can modify that code before it reaches you. They can hack the download site, impersonate it with DNS spoofing or cache poisoning, convince the system to redirect to a different site, or even modify the code in transit as it crosses the network. This scenario even applies to cases in which your own product downloads and installs updates.
Improper Resource Shutdown or Release
When your system resources have reached their end-of-life, you dispose of them: memory, files, cookies, data structures, sessions, communication pipes, and so on. Attackers can exploit improper shutdown to maintain control over those resources well after you thought you got rid of them. Attackers may sift through the disposted items, looking for sensitive data. They could also potentially reuse those resources.
Improper Initialization
If you don't properly initialize your data and variables, an attacker might be able to do the initialization for you, or extract sensitive information that remains from previous sessions. If those variables are used in security-critical operations, such as making an authentication decision, they could be modified to bypass your security. This is most prevalent in obscure errors or conditions that cause your code to inadvertently skip initialization.
Incorrect Calculation
When attackers have control over inputs to numeric calculations, math errors can have security consequences. It might cause you to allocate far more resources than you intended - or far fewer. It could violate business logic (a calculation that produces a negative price), or cause denial of service (a divide-by-zero that triggers a program crash).
Improper Access Control (Authorization)
If you don't ensure that your software's users are only doing what they're allowed to, then attackers will try to exploit your improper authorization and exercise that unauthorized functionality.
Use of a Broken or Risky Cryptographic Algorithm
Grow-your-own cryptography is a welcome sight to attackers. Cryptography is hard. If brilliant mathematicians and computer scientists worldwide can't get it right -- and they're regularly obsoleting their own techniques -- then neither can you.
Hard-Coded Password
Hard-coding a secret account and password into your software is extremely convenient -- for skilled reverse engineers. If the password is the same across all your software, then every customer becomes vulnerable when that password inevitably becomes known. And because it's hard-coded, it's a huge pain to fix.
Insecure Permission Assignment for Critical Resource
Beware critical programs, data stores, or configuration files with default world-readable permissions. While this issue might not be considered during implementation or design, it should be. Don't require your customers to secure your software for you! Try to be secure by default, out of the box.
Use of Insufficiently Random Values
You may depend on randomness without even knowing it, such as when generating session IDs or temporary filenames. Pseudo-Random Number Generators (PRNG) are commonly used, but a variety of things can go wrong. Once an attacker can determine which algorithm is being used, he can guess the next random number often enough to launch a successful attack after a relatively small number of tries.
Execution with Unnecessary Privileges
Your software may need special privileges to perform certain operations; wielding those privileges longer than necessary is risky. When running with extra privileges, your application has access to resources that the application's user can't directly reach. Whenever you launch a separate program with elevated privileges, attackers can potentially exploit those privileges.
Client-Side Enforcement of Server-Side Security
Don't trust the client to perform security checks on behalf of your server. Attackers can reverse engineer your client and write their own custom clients. The consequences will vary depending on what your security checks are protecting, but some of the more common targets are authentication, authorization, and input validation.

Most Popular Programming Language

Debate over the most popular programming language can become an emotional, almost religious battle. And sometimes there's no debate at all, such as when a developer is assigned to repair legacy software. "It was written in COBOL?" is a popular refrain.

A programming language is just one tool in a developer's expansive collection of specialty software and hardware. So does it really matter which programming language a developer uses, as long as he or she is meeting customer requirements on time and within budget?

Yes, yes it does. Ford or Chevy. Stihl or Husky. Coke or Pepsi. Let's face it, we all get passionate about our tools.

Tiobe.com

Tiobe is a popular site for ranking programming languages. Tiobe bases its rankings on world-wide availability of skilled engineers, courses and third party vendors. Rankings are not about the best programming language or the language in which most lines of code have been written. Tiobe uses Google, MSN and Yahoo! search engines to measure the Web "chatter" and hence the popularity of each programming language. The Tiobe top 11 for May 2007 are:

1. Java – 19.1%
2. C – 15.2%
3. C++ – 10.1%
4. PHP – 8.7%
5. Visual Basic – 8.4%
6. Perl – 6.2%
7. Python – 3.8%
8. C# – 3.7%
9. JavaScript – 3.1%
10. Ruby – 2.6%
11. Delphi – 2.1%

Dice.com

A September 2006 eWeek article ranks programming languages based on nationwide queries on Dice.com, a job site for technology professionals. Following are percentage of jobs listed on Dice.com that require skills in each programming language:

1. Java – 35.7%
2. C, C++ – 15.3%
3. C# – 12.7%
4. Perl – 11.9%
5. JavaScript – 10.9%
6. Visual Basic .NET – 5.2%
7. PHP – 2.9%
8. Ajax – 2.7%
9. Python – 2.0%
10. Ruby – 0.7%

Evans Data

Evans Data Corporation conducted a Winter 2006 developer survey that ranks programming languages based on how many developers use that language at least some of the time:

1. Java – 45%
2. C, C++ – 40%
3. C# – 32%
4. Ajax – 28%
5. Visual Basic & VB.NET – 21%

Computerworld

In early 2005, Computerworld conducted a developer survey that measured which programming languages are in use by the developer's company:

1. C# – 72%
2. Java – 66%
3. Visual Basic – 62%
4. C++ – 54%
5. JavaScript – 50%
6. Unix Shell Scripts – 42%
7. Perl – 34%
8. C – 32%
a

Most Popular Programming Language

Yes, yes it does. Ford or Chevy. Stihl or Husky. Coke or Pepsi. Let's face it, we all get passionate about our tools.

Tiobe.com

1. Java – 19.1%
2. C – 15.2%
3. C++ – 10.1%
4. PHP – 8.7%
5. Visual Basic – 8.4%
6. Perl – 6.2%
7. Python – 3.8%
8. C# – 3.7%
9. JavaScript – 3.1%
10. Ruby – 2.6%
11. Delphi – 2.1%

Dice.com

1. Java – 35.7%
2. C, C++ – 15.3%
3. C# – 12.7%
4. Perl – 11.9%
5. JavaScript – 10.9%
6. Visual Basic .NET – 5.2%
7. PHP – 2.9%
8. Ajax – 2.7%
9. Python – 2.0%
10. Ruby – 0.7%

Evans Data

Evans Data Corporation conducted a Winter 2006 developer survey that ranks programming languages based on how many developers use that language at least some of the time:

1. Java – 45%
2. C, C++ – 40%
3. C# – 32%
4. Ajax – 28%
5. Visual Basic & VB.NET – 21%

Computerworld

In early 2005, Computerworld conducted a developer survey that measured which programming languages are in use by the developer's company:

1. C# – 72%
2. Java – 66%
3. Visual Basic – 62%
4. C++ – 54%
5. JavaScript – 50%
6. Unix Shell Scripts – 42%
7. Perl – 34%
8. C – 32%
a

Host a Website on Your Home Computer for Free

This tip will show you how to host a website on your home computer for free using IIS in six easy steps. Performing these six steps will greatly help you understand ASP.NET programming in general.

Even if you do not have a practical need to host your own website, learning how everything works is of fundamental importance, and it is a great exercise for everyone. You can view the complete post that describes the details for each step by clicking on this link: Host a Website on Your Home Computer for Free.

Step 1: Make sure you have IIS installed.

Step 2: Add a website to IIS

Step 3: Open Port 80 to Make a website Accessible from the Internet

Step 4: Determine if your home computer uses a Static or Dynamic IP Address

Step 5: Handle a Dynamic IP Internet connection (if not using Static IP)

Step 6: Register Domain Name (if you do not want to just use IP Address)

( ';')< "ЦΓΤІШΛΤΞ ΠΛΡΣΤЯ"

Tag Cloud

Pages

Wednesday, October 19, 2011

NT Security

NT Security

Thursday, August 18, 2011

Top 25 Most Dangerous Programming Mistakes

Top 25 Most Dangerous Programming Mistakes

Most Popular Programming Language

Most Popular?

Tiobe.com

Dice.com

Evans Data

Computerworld

Most Popular Programming Language

Most Popular?

Tiobe.com

Dice.com

Evans Data

Computerworld

Host a Website on Your Home Computer for Free

Geo IP Location

BlogSearch:

Blog Visited