|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
See also |
Recommended books |
Recommended Articles | Referential integrity | ||||
| Tools and Scripts | Oracle security | PostgreSQL Security | MySQL security | Admin Horror Stories | Random Findings | Humor | Etc |
|
|
This page contains links and reading material for my "eCommerce Security" class. It is pretty superficial. Some links might be broken. Do not complain. Use Google to find a new links, if any.
|
|
Web databases security is one of the most challenging aspects of network security. Put simply, application-level security ensures that business applications interact with end users only in ways that were intended by the application�s developers. Application-level security is focused on preventing the unauthorized use of a networks� resources or customer information by hackers attempting to gain access to the business network directly through the application itself. Application-level hacks typically exploit various weaknesses in WEB applications. Some of them became so prominent that got special names "Referential Integrity problem" or "SQL injection". The latter is in essence very similar to CGI exploits:
SQL injection, or SQL poisoning, should actually be familiar to anyone who has read my articles about securing Web servers. SQL injection is an attack very similar to those that are used against CGI (Common Gateway Interface) programs or scripts. In SQL injection, the attacker includes something in a response from a Web browser that the script writer didn't anticipate. The main difference between SQL injection and other CGI attacks is that the attack relies on some basic understanding of SQL.
The problem is that unlike WEB server Web applications today often access databases that house some of the most valuable assets a company has, namely information about their customers and products.
Here is some intro information (from Basics of SQL Security) :
Schema - is a named collection of objects associated with a particular user.
Privilege - is a right to execute a particular type of SQL command or to access another user's objects.
There are two types of privileges: system privileges and object privileges.
System Privilege - is the right to perform a particular "system" action, or to perform an action on any schema object of a particular type.
Object Privilege - is the right to perform a particular action on a specific object (table, view, sequence, procedure, function, or package).
Views
If you are creating a view, you must have explicitly granted object/system (SELECT, INSERT, UPDATE, DELETE / SELECT ANY TABLE, INSERT �, UPDATE �, DELETE �) privileges on all base objects underlying the view.
In order to grant other users access to your view, they should have explicitly granted object privileges on all base objects underlying the view. It's convenient if the owner of the view was granted privileges on these objects with GRANT OPTION; he will be able to grant required privileges to other users.
The current privileges of the owner of a view are always checked before the view is used. If privileges have been revoked then neither owner nor other users can use the view.
Procedures
If you are creating a procedure, you must have explicitly granted object/system privileges on all base objects underlying the procedure.
Other users require only execute privilege on the procedure and do not require privileges on underlying objects.
The current privileges of the owner of a stored procedure are always checked before the procedure is executed. If privileges have been revoked then neither owner nor other users can execute the procedure.
Triggers
The same situation as with procedures.
Packages
A user with the EXECUTE privilege on a package can execute any procedure within this package.
ADMIN/GRANT option in GRANT statement
Use ADMIN OPTION to grant system privileges or roles.
Use GRANT OPTION to grant object privileges.
A grant with ADMIN/GRANT option supersedes a previous identical grant without this option. A grant without ADMIN/GRANT option does not supersede a previous grant with this option.
To revoke ADMIN/GRANT option - you must revoke the privilege/role, then make a new grant without ADMIN/GRANT option.
LockwoodTech Software - RAD development tools for VB, ASP and SQL developers
Using Stored Procedures to manage SQL Security
Stored Procedures offer an opportunity to improve your database security. By denying read (SELECT) and write (INSERT, UPDATE, and DELETE) access to all database tables and providing only EXECUTE privileges to your stored procedures you can ensure that your data can be accessed in a much more controlled, restricted medium. Ad hoc SQL no longer will be able to access your data. All Data Access must pass through Stored Procedures and be subject to any validation, security, logging etc. that you care to implement at this layer.
Google matched content |
Open Directory - Computers Software Databases
searchDatabase.com/Security good links
Securing the Database: What are the Issues? By Tom Turner
...While relational databases provide basic authentication, authorization and auditing features, they are incomplete and inflexible. Furthermore, databases are lacking easy to use, security specific management interfaces that simplify the complex and time-consuming task of administering security. There is also no way to safely assign this function to the security group without elevating privilege. To remedy these problems a company must either write their own programs or rely on a third-party solution. Such a solution must address the challenges of cost-effectively implementing, managing, monitoring and enforcing strong authentication, authorization, and auditing controls at the database level.
Authentication issues
Strong authentication is the cornerstone of any security implementation plan. Without it, enforcing authorization controls and creating a meaningful audit trail are not possible. While relational databases provide the ability to prompt a user for a password before allowing access, features to enforce the use of strong passwords are nonexistent or limited and inflexible. For example, there may be no ability to force a user to periodically change their password, which is a tenet of every corporate security policy. If the database is able to force a periodic password change, it is often limited in its ability to completely enforce corporate password standards (minimum length, alphanumeric requirements, reuse limitations, etc.) that reduce the risk of the password being guessed.Relational databases also often lack the ability to detect possible break-ins and automatically disable a user ID that may be under attack. Without this feature, an intruder would be granted an unlimited number of attempts to guess a password, thus increasing the chances of successful break-in. If the database does include such a feature, it often lacks the ability to enable it selectively by user ID. Sometimes there is no option to only generate an alert to the security console instead of disabling the user ID. This inflexibility can render the feature unusable because key user ID�s can be accidentally or intentionally disabled.
Authorization issues
A user�s function within the organization determines her authorized level of access to applications, system resources and the database. The user�s authorizations can be set at the database level by granting privileges and roles to the database user ID and by setting the appropriate access controls on specific database objects such as tables. These must be defined for each user when the database user ID is created along with other parameters such as system resource and table space quotas. Authentication parameters such as password expiration and minimum length settings must also be specified for each user. There are typically no provisions to store other useful information such as the user�s full name, department, telephone number, etc. In addition, if the user is granted access to the database through an application, the relevant application specific parameters must be set up within the application�s security tables. All of these tasks fall under the heading of user security administration.Security administration issues
Fortifying the security controls in the database is a desirable goal, but at the same time a mechanism for administering these controls must be set up. Unfortunately, enabling password expiration, password standards enforcement, break-in detection and dormant user ID identification can create an administrative burden on the database administrator (DBA), who is often the only one with enough authority and technical expertise to perform the tasks. There are no facilities to allow the restricted delegation of password administration to security personnel or the help desk without elevated privilege. Built-in facilities to report on relevant statistics and password related audit events do not exist. The result is an operational roadblock to implementing strong database authentication because the DBA simply does not have the time to take on another task.The operational challenge of user security administration arises out of the fact that setting up and managing database authorization elements requires technical expertise and elevated privilege. Furthermore, each element is defined using a separate utility or group of commands. If there are multiple databases where the user�s authorizations must be defined, the task becomes monumental. The commands must be repeated for each database and there is no central repository for easily modifying and deleting user security settings on multiple databases simultaneously.
The human resources required to implement, monitor and manage security at all levels within most organizations today are scarce and expertise is limited. Good security policy and operational efficiency dictates that user security administration be handled by the security administration group. This group often already has responsibility for user security administration at the mainframe level and utilizes mature third-party security software such as RACF�, ACF2� and Top Secret�. These tools automate the security function and insulate them from the need for elevated privilege and the technical eccentricities of the mainframe operating system�s user interface. Today, however, most information security departments are under-staffed, under-budgeted and under-supported. They have limited technical expertise at the database level and lack the tools to take on database security administration. Granting them the elevated privileges required to do the job could result in accidental disruption of database service or performance problems.
Auditing issues
In addition to strong authentication and authorization controls, corporate security policy requires that audit trails be maintained at the database level to insure data integrity and to detect possible security breaches or intrusions. Although many third-party software applications drawing on an RDBMS have built-in auditing capabilities, they are usually incomplete and only record events that take place through the application, thus leaving any backdoor access to the database unrecorded.While most databases have built-in audit utilities, they are complex and do not provide enough detail to meet corporate auditing requirements. As a result, native database auditing utilities are often disabled. If they have been enabled, they usually are set to track a small subset of all the events required to meet corporate security policy due to a fear of creating performance problems or disk storage overhead. Logged audit events are rarely reviewed because the data are cryptic and too voluminous to be useful. There is no easy-to-use-reporting tool for filtering out irrelevant audit events or drilling down for more detail about suspicious activities. This also complicates the process of purging excess audit data and archiving significant audit events. These problems are compounded if multiple database audit trails must be maintained.
A major problem with native database auditing utilities is the inability to track both before and after value detail on changes made to data within tables. This information is critical for creating a meaningful audit trail because it provides the means to determine if access rights have been abused. It also allows the correction of data that has been intentionally or accidentally modified in an unauthorized manner. In addition, the database does not provide a simple method for sending real-time alerts to the security console when time-sensitive critical audit events such as break-ins occur.
Setting up, maintaining and making use of audit trails at the database level is difficult and time-consuming. The requirement for elevated privilege and knowledge of complex SQL commands combined with the lack of easy-to-use reporting tools usually dictates that the already busy DBA be involved. While the DBA should be consulted on the performance ramifications of enabling auditing, good security policy would delegate the task to the corporate security function. Both audit functionality and viewable data should be restricted based upon the job function and department of the employee to whom the task is assigned.
Referential integrity - Webopedia.com
A feature provided by relational database management systems (RDBMS's) that prevents users or applications from entering inconsistent data. Most RDBMS's have various referential integrity rules that you can apply when you create a relationship between two tables.
For example, suppose Table B has a foreign key that points to a field in Table A. Referential integrity would prevent you from adding a record to Table B that cannot be linked to Table A. In addition, the referential integrity rules might also specify that whenever you delete a record from Table A, any records in Table B that are linked to the deleted record will also be deleted. This is called cascading delete. Finally, the referential integrity rules could specify that whenever you modify the value of a linked field in Table A, all records in Table B that are linked to it will also be modified accordingly. This is called cascading update.
InformIT.com Articles Relationships Your Key to Data Integrity in Access
Integrity Rules
Although integrity rules are not part of normal forms, they are definitely part of the database design process. Integrity rules are broken into two categories. They include overall integrity rules and database-specific integrity rules.
Overall Rules
The two types of overall integrity rules are referential integrity rules and entity integrity rules. Referential integrity rules dictate that a database does not contain any orphan foreign key values. This means that
- Child rows cannot be added for parent rows that do not exist. In other words, an order cannot be added for a nonexistent customer.
- A primary key value cannot be modified if the value is used as a foreign key in a child table. This means that a CustomerID cannot be changed if the orders table contains rows with that CustomerID.
- A parent row cannot be deleted if child rows are found with that foreign key value. For example, a customer cannot be deleted if the customer has orders in the order table.
Entity integrity dictates that the primary key value cannot be Null. This rule applies not only to single-column primary keys, but also to multi-column primary keys. In fact, in a multi-column primary key, no field in the primary key can be Null. This makes sense because, if any part of the primary key can be Null, the primary key can no longer act as a unique identifier for the row. Fortunately, Access does not allow a field in a primary key to be Null.
Database-Specific Rules
The other set of rules applied to a database are not applicable to all databases, but are, instead, dictated by business rules that apply to a specific application. Database-specific rules are as important as overall integrity rules. They ensure that only valid data is entered into a database. An example of a database-specific integrity rule is that the delivery date for an order must fall after the order date.
PostgreSQL CBT - Referential Integrity
Referential Integrity Tutorial & Hacking the Referential ...
Extended Referential Integrity (1)
A Scalable Architecture for Maintaining Referential Integrity in ...
Declarative referential integrity v/s triggers.
Free Flash based Referential Integrity tutorial
[Oct 23, 2002]
SQLSecurity.com-
Microsoft SQL Server Webtasks privilege elevation
Another month, another privilege escalation. Here, an extended
stored procedure (xp_runwebtask) fails to check permissions and results in an immediate
privilege escalation. Hosting providers worldwide beware! Of course, per the checklist
you should have either removed this procedure or removed public access.
read more...
CERT Advisory CA-2002-22 Multiple Vulnerabilities in Microsoft SQL Server
N-008: Microsoft Elevation of Privilege in SQL Server Web Tasks
SecurityFocus home vulns solution- Progress Database Multiple ...
New Elevation of Privileges SQL Server Security Patch Available
Microsoft Security Bulletin MS02-061
[PDF] Hack-proofing Oracle 9iAS
OpenNET security Oracle Security Followup, patch and FAQ setuid on oratclsh
Date: Thu, 6 May 1999 16:01:17 -0700
From: John Ritchie <[email protected]>
To: [email protected]
Subject: Oracle Security Followup, patch and FAQ: setuid on oratclsh
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to [email protected] for more info.
--=====================_926048157==_
Content-Type: TEXT/ENRICHED; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <[email protected]>
All,
The following message and patch was sent to us from Oracle regarding the
oratclsh setuid vulnerability. If you're an Oracle Metalink member you
can get this patch off their website; if not then here it is.
Note that this removes oratclsh completely, and removes setuid bits from a
whole bunch of other executables. I see this is a good sign: maybe Oracle
is starting to get as nervous about weak setuid protections as we all are.
:^)=20
I've removed all the HTML formatting from the following FAQ.
John Ritchie
Systems Software Analyst
Oregon University System
---------- Forwarded message ----------
[Oracle contact names removed to protect the innocent]
This e-mail is in response to your concern expressed in your e-mail
entitled: "*Huge* security hole in Oracle 8.0.5 with Intellegent agent".=
=20
The Oracle Security Development team, along with the Oracle Worldwide
Support group have looked into this issue. We've done research and found
the setuid issue extended a bit beyond the oratclsh file.=20
So, attached is a patch in the form of a shell script which we are
issuing today to our customers via our Worldwide Customer Support web
page (MetaLink). Also below this message is the FAQ about this patch,
which is also being posted to MetaLink.=20
[more Oracle Support name info deleted]
Q: I've heard about a setuid security issue with the Oracle database? What is this all about?
A: On Unix platforms, some executable files have the setuid bit on. It may be possible for a very knowledgeable user to use these executables to bypass your system security by elevating their operating system privileges to that of the Oracle user.
Q: I've also heard about a security issue with the Intelligent Agent? What is this all about?
A: It's basically the same problem as above, but specifically applies to a utility executable called oratclsh which is included in your Intelligent Agent installation. It is a separate program that is not used by the Intelligent Agent.
Q: Which releases are affected by this problem?
A: This problem affects Oracle data server releases 8.03, 8.0.4, 8.0.5, and 8.1.5 on UNIX=99 platforms only.
Q: Can I correct this problem or do I need a patch?
A: This problem can easily be corrected. The customer can download the patch from the Oracle MetaLink webpages at
<<http://www.oracle.com/support/elec_sup>http://www.oracle.com/support/elec=
_sup.=20
The patch is a UNIX shell script. This shell script should be run immediately, and also run after each
relink of Oracle.
Q: Is the Oracle Intelligent Agent secure?
A: Yes, the Oracle Intelligent Agent is secure. All tasks performed by the Intelligent Agent require username/password authentication. The Intelligent Agent can only perform a task for which appropriate credentials -- for the operating system and/or database -- have been provided.
Q: What is Oracle doing to fix this problem?
A: Effective immediately, Oracle will provide the patch on Oracle's Worldwide Support Web pages. Oracle will ensure the patches are incorporated into future releases of Oracle8i (8.1.6) and Oracle8.0 (8.0.6).
Q: What is Oracle doing to notify users about this problem now?
A: Oracle is notifying all supported customers, via the Oracle Worldwide Support Web pages, of this issue so they can address it as required.
=====================_926048157==_
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <[email protected]>
Content-Description: setuid_patch.sh
#!/bin/sh
#
# NAME
# setuid_patch.sh
#
# DESCRIPTION
# Provided as a patch to 8.0.X and 8.1.5 to fix bugs 701297, 714293.
# These bugs introduce a security hole by changing the permissions
# to affect the effective user id for executables which should not
# be set this way.
#
# PRECONDITIONS
# if ORACLE_HOME is not set, doesn't exist, or points to an
# invalid location, script exits.
#
# HOW TO USE
# This script must be run as the oracle user who installed the 8.0.3
# 8.0.4, 8.0.5 or 8.1.5 software.
#
# To run, change directories into the the directory that contains this
# file.
# % cd <patch_location_directory>
#
# Add execute permission to the patch.
# % chmod 744 setuid_patch.sh
#
# Then, invoke the script.
# % ./setuid_patch.sh
#
# MODIFIED (MM/DD/YY)
# menash 5/3/99 Initial creation
##---------------------
## VARIABLE DEFINITIONS
#-----------------------------
# potentially platform specific variables
CHMOD="/bin/chmod"
FIND="/bin/find"
CHMOD_S="$CHMOD -s" # remove set id bit
RM_F="/bin/rm -f"
LS_L="/bin/ls -l"
LS_N="/bin/ls -n" # gives uid number for owner
SED="/bin/sed"
AWK="/bin/awk"
GREP="/bin/grep"
GREP_C="$GREP -c"
GREP_V="$GREP -v"
MV="/bin/mv"
TMP_DIR="/tmp"
EXECS_TO_UNSET="lsnrctl oemevent onrsd osslogin tnslsnr tnsping trcasst trcroute cmctl cmadmin cmgw names namesctl otrccref otrcfmt otrcrep otrccol oracleO"
EXECS_NOT_TO_UNSET="oracle dbsnmp"
EXECS_TO_REMOVE="oratclsh osh"
LIKELY_SUFFIXES="0 O"
ROOT_SH_815="$ORACLE_HOME/root.sh"
ROOT_SH_805="$ORACLE_HOME/orainst/root.sh"
if [ x${ORACLE_HOME} = x ] -o [ ${ORACLE_HOME} = "" ] ; then
echo "ORACLE_HOME is either unset or empty."
echo "Exiting ..."
exit 1
fi
#--------------
# usage message
SCRIPTNAME=setuid_patch.sh
USAGE="Usage: $SCRIPTNAME [-h]"
if [ $# -gt 1 ] ; then
echo
echo $USAGE
exit 2
fi
##-----------#
## FUNCTIONS #
##-----------#
# ----------
# setuid_off
# Assumes executable is in $ORACLE_HOME/bin
#
# Usage: setuid_off <executable>
#------------
setuid_off () {
exe=$1
full_path_exe=$ORACLE_HOME/bin/$exe
if [ -r $full_path_exe ] ; then
perm=`$LS_L $full_path_exe | $SED 's;r-.*;;'`
if [ $perm = "-rws" ] ; then
$CHMOD_S $full_path_exe
echo " removing set-ID from $full_path_exe"
fi
fi
}
#-----------
# remove_exe
# Assumes executable is in $ORACLE_HOME/bin
# Removes if owned by root, otherwise, calls setuid_off
# Usage: remove_exe <executable>
remove_exe () {
full_path_exe=$ORACLE_HOME/bin/$1
if [ -r $full_path_exe ] ; then
owner=`$LS_N $full_path_exe | $AWK '{print $3}'`
if [ $owner = "0" ] ; then
$RM_F $full_path_exe
echo " removing $full_path_exe..."
else
setuid_off $1
fi
fi
}
#-----------
# search_for_others
#
# Finds other executables n $ORACLE_HOME/bin which have 4000, 6000,
# or 2000 permissions except for those we expects, and warns the
# user that they should be removed manually
# Usage: search_for_others
search_for_others () {
all_others="`$FIND $ORACLE_HOME/bin -perm -2000`"
others=""
if [ x"${all_others}" != x ] ; then
for other in $all_others; do
match="false"
for exe in $EXECS_NOT_TO_UNSET; do
if [ $other = $ORACLE_HOME/bin/$exe ] ; then
match="true"
fi
done
if [ $match = "false" ] ; then
others="$others $other"
fi
done
if [ x"${others}" != x ] ; then
echo "The following executables remain with set-ID."
echo "You may need to change the permissions manually:"
for executable in $others; do
echo " $executable"
done
fi
fi
}
#--------
# remove_from_root_sh
# For each parameter it is passed, remove_from_root_sh removes all
# lines with references to that string.
# Usage: remove_from_root_sh [ string1, string2, etc. ]
remove_from_root_sh () {
strings=$*
tmp_file="root.sh.$$"
$RM_F $TMP_DIR/$tmp_file
for string in $strings; do
if [ `$GREP_C $string $ROOT_SH` != "0" ] ; then
echo " removing $string from $ROOT_SH"
fi
$GREP_V $string $ROOT_SH > $TMP_DIR/$tmp_file
$MV $TMP_DIR/$tmp_file $ROOT_SH
done
}
################
# MAIN EXECUTION
################
# Turn setuid bit off for the appropriate executables and their
# likely backups
for exe in $EXECS_TO_UNSET; do
setuid_off $exe
for suf in $LIKELY_SUFFIXES; do
setuid_off $exe$suf
done
done
# Remove files entirely which should be removed
for exe in $EXECS_TO_REMOVE; do
remove_exe $exe
done
# Determine version -- 8.0.5 or 8.1.5
# Backup existing root.sh into root.sh.old, removing references
# to EXECS_TO_REMOVE
if [ -r $ROOT_SH_805 ] ; then
ROOT_SH=$ROOT_SH_805
else
if [ -r $ROOT_SH_815 ] ; then
ROOT_SH=$ROOT_SH_815
else
echo "No root.sh found in $ORACLE_HOME"
fi
fi
if [ x${ROOT_SH} != x ] ; then
remove_from_root_sh $EXECS_TO_REMOVE
fi
# Check one last time to see if any setuid executables are left
search_for_others
New Order - computer security and networking portal SQL related tools
Internet Data and Application Security
Vigilar Web Application and Database Security
| Solution Benefits | ||||
|
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater�s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright � 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
