My point is that with Oracle, DB2, PostgreSQL one has to construct a compound SQL statement as a block starting with BEGIN and terminating with an END. That makes it very difficult to inject a second SQL statement. MS SQL does not have this requirement, hence the (much increased) vulnerability.
That said, I wouldn't be completely surprised if some Microsoft ADO drivers for the above databases add the same "feature" in the name of SQL Server compatibility. As for myself, I avoid Microsoft server technologies like the plague.
Twenty or so years ago, using dynamically generated SQL was expensive, slow, and hard to program. The vast majority of SQL applications were written with SQL statically embedded in C, FORTRAN, or COBOL dialects that had to be translated to the base language using a precompiler.
Parameters were bound by name to host language variables, and the precompiler handled the mapping to the underlying database library. Much more secure than dynamic SQL without bound parameters.
Of course as computers got faster, the penalty for not binding parameters was reduced. Application language developers got lazy and added SQL APIs without any way to bind parameters at all. ColdFusion was this way for years, for example. The first time I saw it I was shocked - not so much for security reasons, as for the low efficiency the lack of such support implied.
In short - barring a few semantically impaired languages - it has always been possible (and once was the far and away predominant practice) to bind typed parameters to SQL statements and avoid potential injection vulnerabilities completely.
That is not correct. MS SQL Server is vulnerable in a way that no other database that I am aware of (Sybase perhaps) due to the way it constructs compound statements.
Oracle is not vulnerable to this type of attack, nor is DB2, nor PostgreSQL. Some databases, like MySQL, are apparently only vulnerable when using a Microsoft ADO driver - same design mistake: support for compound statements without requiring block structure (BEGIN / END) allows trivial injection of arbitrary SQL.
Microsoft SQL Server is particularly vulnerable to SQL injection in a way that most other databases aren't. The problem is multiple statement execution just by inserting semicolons.
Catalog access isn't much of a vulnerability if an attacker cannot trivially execute SQL ad lib. with a single unchecked parameter.
The problem here is that MS SQL Server supports multiple statements in the same prepare / execute block in an unsafe manner. Just insert a semicolon and off you go.
The safe way to support multiple statement execution ("query stacking") is with something like the block syntax of Oracle. Given a single unchecked entry field, the SQL Server syntax is trivially exploitable do anything the attacker wants.
The problem is not SQL Server's support of multiple statements, but rather the way they do it. Oracle supports multiple statements, but only in a PL/SQL begin end block, which is generally speaking impossible to inject.
SQL Server on the other hand is trivially exploitable if any parameter is unchecked, due to the way statements are chained together - no block syntax required, just a semicolon and anything goes after that.
SQL Server is far more vulnerable to this kind of attack because of the way it allows multiple statements to be parsed and executed together. In Oracle for example, this attack could never have occured because multiple statement execution requires creating a PL/SQL block that starts with a "begin" and terminates with an "end". Whereas in SQL Server any unvalidated semicolon is sufficient to start a new statement.
That doesn't mean that Oracle and most other databases are invulnerable to SQL injection, but rather that insecure web applications that use them are much less likely to be exploited than those that use SQL Server are. With most databases and a typical insecure web application, a thoughtful attacker can usually only compromise the database piecemeal. With SQL Server and an insecure web app its game over without a second thought.
Employees whose salaries are paid from an appropriation for the Executive Office of the President have looser constraints on their participation in political activities than other federal employees (c.f. 5 USC 7324). However, this participation requires that costs associated with the activity not be paid for by funds derived from the United States Treasury.
Thus sending partisan political communication through an external server is hardly in defiance of the law, but rather in compliance with the law. There is nothing wrong with that - the only problem is the improper use of outside email for official business.
The solution is very simple - Congress can either amend section 7324 to allow the use of White House email addresses for such activity (while prohibiting the use of external addresses) or it can require that all such communication be "carbon copied" to a White House email address for archiving.
I think the bizarre name (for a software package) is a greater drag on "OpenOffice.org" than anything the management committee might be doing. If they really think "Office" is a Microsoft trademark they should name it something else. Anything but stick an awkward top level domain identifier on the end. That is a marketing disaster.
I imagine they invoked the DMCA because a superficial reading of the pertinent provisions would lead one to believe that DMCA take down notices are applicable to this kind of activity.
Unfortunately for Autodesk, that is pretty clearly not the case. The DMCA is about copyright infringement, not breach of contract, shrinkwrap or otherwise. In addition, Section 512 take down notices only apply to online material accessible through a service provider. No one's copyrights were being infringed here and the copyrighted material was not online. Quite the opposite. The First Sale Doctrine (codified in 17 USC 109) establishes that:
Notwithstanding the provisions of section 106 (3), the owner of a particular copy or phonorecord lawfully made under this title, or any person authorized by such owner, is entitled, without the authority of the copyright owner, to sell or otherwise dispose of the possession of that copy or phonorecord.
Of course there are tradeoffs, but a natural key only policy in a relational database of any sophistication is more or less insane. The biggest problem is that natural keys add at least one column for each level you go down in a database hierarchy. It is not uncommon for the natural key at the detail level of a typical snowflake table structure to have four or five columns.
And of course all of these columns have to be carried in all foreign keys, including primary foreign keys as well. So suddenly, simple association tables have *ten* primary key columns. That is a programming nightmare. Any relational database that requires more than two columns per table join on average is going to be difficult to manage, develop for, and maintain. It is also going to waste a lot of unnecessary resources.
In addition, a no synthetic key policy forces users to come up with unique identifiers instead of the database in cases where they do not care and where it is unnecessary. That is bad user interface design, plain and simple. Names and descriptions are usually unique - certainly enough for user purposes, but what kind of system uses a free form text field as a primary or foreign key?
Worse, if anything the user can change is used as a primary key, cascading updates will be required. Cascading updates are inefficient and most databases do not do them automatically.
Row/column hybrids are a good idea, but there are a half dozen technical reasons why data in different formats won't work for redundancy. The big problem is those functions are in radically different sections of the system. The disk controller doesn't know anything about the database and vice versa.
Also, modern databases never have to wait for data blocks to actually hit the disk during normal operation. They only have to wait for log records to actually hit the disk (at transaction commit time). Once the log records are persistent, if the system crashes, they can be used during the database recovery process to bring all the data blocks back up to date.
Journalling file systems are similar, except usually only with regard to meta data changes.
The sentence is clear. The second "or" is in a different clause than the first. It is part of a clause that specifies what the purpose or effect of the (expected) violence must be for the order to apply.
In other words, rather than expanding the scope of the order to "thought crimes", it restricts the scope to violence or conspiracy to commit violence that has a specific purpose - undermining recovery efforts in Iraq.
Scanning insufficient to establish copyright
on
False Copyright Claims
·
· Score: 5, Informative
According to Bridgeman Art Library v. Corel Corporation, scanning a public domain image isn't sufficient to establish copyright on the result, even if considerable skill and expertise is required.
Speaking of 'ignorance is no excuse'...
on
False Copyright Claims
·
· Score: 2, Informative
A U.S. district court issued a decision in Bridgeman Art Library v. Corel Corp. that indicates that copying a stock image of the Mona Lisa would likely not violate the law.
Probably not. According to the Media Law Resource Center:
In order for the person about whom a statement is made to recover for libel, the false statement must be defamatory, meaning that it actually harms the reputation of the other person, as opposed to being merely insulting or offensive.
The statement(s) alleged to be defamatory must also have been published to at least one other person (other than the subject of the statement) and must be "of and concerning" the plaintiff. That is, those hearing or reading the statement must identify it specifically with the plaintiff.
The statement(s) alleged to be defamatory must also be a false statement of fact. That which is name-calling, hyperbole, or, however characterized, cannot be proven true or false, cannot be the subject of a libel or slander claim.
The defamatory statement must also have been made with fault. The extent of the fault depends primarily on the status of the plaintiff. Public figures, such as government officials, celebrities, well-known individuals, and people involved in specific public controversies, are required to prove actual malice, a legal term which means the defendant knew his statement was false or recklessly disregarded the truth or falsity of his statement. In most jurisdictions, private individuals must show only that the defendant was negligent: that he failed to act with due care in the situation.
'Sweat of the brow' not copyrightable
on
False Copyright Claims
·
· Score: 2, Interesting
You might want to review Feist Publications v. Rural Telephone Service, in which the Supreme Court ruled that copyright protects creative expression, not 'sweat of the brow'.
So while there may be something about your e-book that is protectable, the OCR of the original text almost certainly does not qualify.
That is a very imaginative theory. However, I don't see any reason to suppose that his activities with SCO affect his reputation with Mormons any more than they might affect his reputation with anyone else though.
Is that something you intend to bet your life on? The example of Korihor is instructive.
And in any case by what means are you so sure that the world of the Spirit does not exist? Does the term Pascal's wager mean anything to you? Is your logic superior to his?
Slashdot Mirror
My point is that with Oracle, DB2, PostgreSQL one has to construct a compound SQL statement as a block starting with BEGIN and terminating with an END. That makes it very difficult to inject a second SQL statement. MS SQL does not have this requirement, hence the (much increased) vulnerability.
That said, I wouldn't be completely surprised if some Microsoft ADO drivers for the above databases add the same "feature" in the name of SQL Server compatibility. As for myself, I avoid Microsoft server technologies like the plague.
Twenty or so years ago, using dynamically generated SQL was expensive, slow, and hard to program. The vast majority of SQL applications were written with SQL statically embedded in C, FORTRAN, or COBOL dialects that had to be translated to the base language using a precompiler.
Parameters were bound by name to host language variables, and the precompiler handled the mapping to the underlying database library. Much more secure than dynamic SQL without bound parameters.
Of course as computers got faster, the penalty for not binding parameters was reduced. Application language developers got lazy and added SQL APIs without any way to bind parameters at all. ColdFusion was this way for years, for example. The first time I saw it I was shocked - not so much for security reasons, as for the low efficiency the lack of such support implied.
In short - barring a few semantically impaired languages - it has always been possible (and once was the far and away predominant practice) to bind typed parameters to SQL statements and avoid potential injection vulnerabilities completely.
That is not correct. MS SQL Server is vulnerable in a way that no other database that I am aware of (Sybase perhaps) due to the way it constructs compound statements.
Oracle is not vulnerable to this type of attack, nor is DB2, nor PostgreSQL. Some databases, like MySQL, are apparently only vulnerable when using a Microsoft ADO driver - same design mistake: support for compound statements without requiring block structure (BEGIN / END) allows trivial injection of arbitrary SQL.
Microsoft SQL Server is particularly vulnerable to SQL injection in a way that most other databases aren't. The problem is multiple statement execution just by inserting semicolons.
Catalog access isn't much of a vulnerability if an attacker cannot trivially execute SQL ad lib. with a single unchecked parameter.
The problem here is that MS SQL Server supports multiple statements in the same prepare / execute block in an unsafe manner. Just insert a semicolon and off you go.
The safe way to support multiple statement execution ("query stacking") is with something like the block syntax of Oracle. Given a single unchecked entry field, the SQL Server syntax is trivially exploitable do anything the attacker wants.
The problem is not SQL Server's support of multiple statements, but rather the way they do it. Oracle supports multiple statements, but only in a PL/SQL begin end block, which is generally speaking impossible to inject.
SQL Server on the other hand is trivially exploitable if any parameter is unchecked, due to the way statements are chained together - no block syntax required, just a semicolon and anything goes after that.
SQL Server is far more vulnerable to this kind of attack because of the way it allows multiple statements to be parsed and executed together. In Oracle for example, this attack could never have occured because multiple statement execution requires creating a PL/SQL block that starts with a "begin" and terminates with an "end". Whereas in SQL Server any unvalidated semicolon is sufficient to start a new statement.
That doesn't mean that Oracle and most other databases are invulnerable to SQL injection, but rather that insecure web applications that use them are much less likely to be exploited than those that use SQL Server are. With most databases and a typical insecure web application, a thoughtful attacker can usually only compromise the database piecemeal. With SQL Server and an insecure web app its game over without a second thought.
Employees whose salaries are paid from an appropriation for the Executive Office of the President have looser constraints on their participation in political activities than other federal employees (c.f. 5 USC 7324). However, this participation requires that costs associated with the activity not be paid for by funds derived from the United States Treasury.
Thus sending partisan political communication through an external server is hardly in defiance of the law, but rather in compliance with the law. There is nothing wrong with that - the only problem is the improper use of outside email for official business.
The solution is very simple - Congress can either amend section 7324 to allow the use of White House email addresses for such activity (while prohibiting the use of external addresses) or it can require that all such communication be "carbon copied" to a White House email address for archiving.
That is a low signal to noise ratio, not a high one.
That is not TCP, but rather BGP (Border Gateway Protocol). TCP handles data transmission and congestion control. It doesn't do routing.
I am sure she will be sent a bill for the damage she caused, and if she doesn't pay up she will likely face a civil suit for the same.
I think the bizarre name (for a software package) is a greater drag on "OpenOffice.org" than anything the management committee might be doing. If they really think "Office" is a Microsoft trademark they should name it something else. Anything but stick an awkward top level domain identifier on the end. That is a marketing disaster.
Unfortunately for Autodesk, that is pretty clearly not the case. The DMCA is about copyright infringement, not breach of contract, shrinkwrap or otherwise. In addition, Section 512 take down notices only apply to online material accessible through a service provider. No one's copyrights were being infringed here and the copyrighted material was not online. Quite the opposite. The First Sale Doctrine (codified in 17 USC 109) establishes that:
It is still nonsense. "Threats" rarely identify anything. It defeats the purpose.
Of course there are tradeoffs, but a natural key only policy in a relational database of any sophistication is more or less insane. The biggest problem is that natural keys add at least one column for each level you go down in a database hierarchy. It is not uncommon for the natural key at the detail level of a typical snowflake table structure to have four or five columns.
And of course all of these columns have to be carried in all foreign keys, including primary foreign keys as well. So suddenly, simple association tables have *ten* primary key columns. That is a programming nightmare. Any relational database that requires more than two columns per table join on average is going to be difficult to manage, develop for, and maintain. It is also going to waste a lot of unnecessary resources.
In addition, a no synthetic key policy forces users to come up with unique identifiers instead of the database in cases where they do not care and where it is unnecessary. That is bad user interface design, plain and simple. Names and descriptions are usually unique - certainly enough for user purposes, but what kind of system uses a free form text field as a primary or foreign key?
Worse, if anything the user can change is used as a primary key, cascading updates will be required. Cascading updates are inefficient and most databases do not do them automatically.
Row/column hybrids are a good idea, but there are a half dozen technical reasons why data in different formats won't work for redundancy. The big problem is those functions are in radically different sections of the system. The disk controller doesn't know anything about the database and vice versa.
Also, modern databases never have to wait for data blocks to actually hit the disk during normal operation. They only have to wait for log records to actually hit the disk (at transaction commit time). Once the log records are persistent, if the system crashes, they can be used during the database recovery process to bring all the data blocks back up to date.
Journalling file systems are similar, except usually only with regard to meta data changes.
The sentence is clear. The second "or" is in a different clause than the first. It is part of a clause that specifies what the purpose or effect of the (expected) violence must be for the order to apply.
In other words, rather than expanding the scope of the order to "thought crimes", it restricts the scope to violence or conspiracy to commit violence that has a specific purpose - undermining recovery efforts in Iraq.
According to Bridgeman Art Library v. Corel Corporation, scanning a public domain image isn't sufficient to establish copyright on the result, even if considerable skill and expertise is required.
Speaking of 'ignorance is no excuse':
s/sediment/sentiment/
s/surounding/surrounding/
s/chalenged/challenged/
s/coledge/college/
s/clrear/clear/
s/willig/willing/
And those are just the spelling errors...
If the additions to the original work consist of original creative expression, then yes. If nothing but 'sweat of the brow', then no.
See Feist Publications v. Rural Telephone Service, Bridgeman Art Library v. Corel.
A U.S. district court issued a decision in Bridgeman Art Library v. Corel Corp. that indicates that copying a stock image of the Mona Lisa would likely not violate the law.
See http://www.medialaw.org/Content/NavigationMenu/Pu
You might want to review Feist Publications v. Rural Telephone Service, in which the Supreme Court ruled that copyright protects creative expression, not 'sweat of the brow'.
. _Rural_Telephone_Service.
So while there may be something about your e-book that is protectable, the OCR of the original text almost certainly does not qualify.
See http://en.wikipedia.org/wiki/Feist_Publications_v
That is a very imaginative theory. However, I don't see any reason to suppose that his activities with SCO affect his reputation with Mormons any more than they might affect his reputation with anyone else though.
Is that something you intend to bet your life on? The example of Korihor is instructive.
And in any case by what means are you so sure that the world of the Spirit does not exist? Does the term Pascal's wager mean anything to you? Is your logic superior to his?