Re:"engineered" by amateur boneheads
on
Verified Voting
·
· Score: 1
I'd love to help, unfortunately my wife roped me into doing some programming for her spiritual group, so I have ZERO spare time at the moment. I'm so over-committed it's not even funny.
I assumed from the user@localhost in the error message that the DB was running on the same box as the web server. I assumed... my mistake
While you may not INTENTIONALLY give users the capability to run ad-hoc SQL, you've UNINTENTIONALLY done just that. The design you're using is (at least potentially) vulnerable to a SQL injection attack. An attacker who compromized the web server or found an exploitable bug in one of your forms would then have full control over the database server as well. The reason for using stored procedures is that this give you an additional access control mechanism to the database. SPs also give you the ability to control access at the row level, whereas native SQL security only lets you controll access at the table or column level.
In a safe design, the webuser db account does not have any select/insert/update/delete permissions on any of the tables directly - all they have is execute permission on the minimal set of stored procedures they need to use the system. This is known as the principle of least privilidge, a basic tenet of secure design.
Stored procedures (at least in Transact-SQL) work along the same basic lines as SUID scripts in Unix -- they run with the rights of their owner, not the executing user's rights. This way a user can perform operations against the database that they otherwise wouldn't have permission to do. This ensures that even if an attacker is able to mount a SQL injection attack, they won't have permission to do anything to the database that they wouldn't be able to do using the authorized interface.
I can see your point about error reporting, however, you need to be aware that it's a security hole. The posted error gives me enough information to plan a SQL injection attack against your system. Also, from a usability standpoint this kind of error reporting sucks -- that message is going to look like gibberish to a non-programmer. The end user needs error messages he can understand. You should by all means write that message to a log file, but don't show it to the user!
There's more to systems engineering than simply being able to code a bug-free application. Mastery of your tools is an important skill, but that's only one small portion of what you need to know.
You have to know how to evaluate different technologies and pick the tool which is most appropriate for the task at hand. Only an amateur just goes with what he knows or what satisfies his political agenda.
You have to know how to design and configure your infrastructure so that it is secure and reliable. You have to know how to calculate anticipated load and how to do capacity planning. You have to know how to test your application -- both functional testing and stress testing. You have to know how to DESIGN an entire system before you jump in and start hacking code.
In other words, you need to act like a professional software engineer, not an amateur code monkey.
"engineered" by amateur boneheads
on
Verified Voting
·
· Score: 1
Who are the clowns who designed this thing? Several incredibly obvious security problems here:
You NEVER spit a raw error message back to an untrusted user, you write it to a (protected) log file. You're leaking information that an attacker can use to compromise the system. The user doesn't need that information, the developer does.
You NEVER give an untrusted user permission to run arbitrary ad-hoc SQL statements against your database -- that's what Stored Procedures are for. If only know how to use a toy database which doesn't support stored procedures then you have no business whatsoever building trustworthy Enterprise applications.
You NEVER put your database server and your web server on the same box in a production enviornment. That's just incredibly stupid in terms of both security and scalability.
Do yourself a favor and hire a real systems engineer with real-world experience designing secure, scalable, and reliable mission-critical systems; not some pathetic geek clown who "knows" php + mysql from putting together his 20-hit-per-day Blog server.
I could care less if the OS is the most spiffy thing on the planet if the compilers used to generate executables for my work are horribly slow
As I noted before, you have your choice of compilers under both Windows and Linux, and there are a number of compilers which are supported on both platforms. GCC is available (and free) on both Win32 and Linux, as is Intel's (pricy) C/C++ compiler. Comparing the performance of GCC-compiled code under Linux with Intel-compiled code under Windows is not a valid comparison of either the compiler or the operating system.
I really want my car to do 1 thing, get me from point A to point B, reasonably efficiently and safely. A modicum of comfort does not hurt either.
Then you have many options that will work for you besides cars[: Walk, Bike, Moped].
Unfortunately for most people those options are neither efficent nor safe. You cannot legally (or safely) walk or ride a bike or moped on an Interstate, which is for a great many people the only practical way to get to work. Likewise, any open-air vehicle is unsafe in rain or snow.
You are comparing apples to oranges -- we're talking about OS performance, not compiler performance. A CPU-intensive application like the one you're talking about is of course going to be highly sensitive to compiler optimizations. Try compiling the application with the same compiler across different platforms -- EG use GCC on Linux & Windows, or use Intel's compiler on both platforms for a valid comparison.
Not all tasks are CPU-Bound. Indeed, most common server-side business tasks (web, email, database) are I/O bound -- either on the disk side or on the network side. My personal experience has been that Linux is significantly more efficient when it comes to pushing big chunks of data around, and it tends to stay more responsive under heavy load than Windows.
Remember that game consoles are basically loss leaders -- they are sold at or below costs, with the profit coming from game sales and licensing fees. If you want to sell a game title for a given console, you have to fork over a hefty up-front fee as well as sizable percentage of the gross.
I bet your hardware runs a lot better/faster on Windows than Linux
I've found just the opposite to be true. I've almost invaribly seen Linux run faster and more reliably than Windows on the same hardware. A couple reasons for this:
Any performance improvement you get from having a highly-optimized driver is typically swallowed up by the general inefficiency of Windows itself.
While the hardware vendor's coders may know their hardware, they don't (and CAN'T, due to it's closed nature) know the Windows internals and how their code will interact with Windows, hence the need for Microsoft to certify the drivers. IME, A *HUGE* number of BSOD errors (perhaps even the majority) are due to misbehaving or buggy vendor-supplied drivers.
The only place Linux falls behind is support for bleeding-edge hardware. This generally isn't a problem for me as I rarely if ever buy leading edge hardware due to it's lousy price/performance ratio. One or two steps back from top-of-the-line usually gives you >90% of the performance for 50% of the price.
Heavy oils on Earth are generally created by chemical processes acting on dead microorganisms over geological time
Change "generally created by" to "generally believed to be created by". There is a (highly contentious) theory that petrochemicals are (or at least can be) formed by abiotic processes. While initially dismissed as a crackpot theory, there does seem to be enough initial supporting evidence to at least warrant further research. The discovery of heavy petrochemicals outside of a biosphere would radically change our understanding of geological processes.
within the USA, First Amendment rights still applied to everyone
Common misconception. The Bill of Rights does not give *YOU* the right to do anything. What it does do is tell *CONGRESS* that they're not allowed to infringe on the rights that all people already have. Repeat after me:
Amendment I:
Congress shall make no law regarding an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances.
Amendment XIV, Section 1: All persons born or naturalized in the United States, and subject to the jurisdiction thereof, are citizens of the United States and of the State wherein they reside. No State shall make or enforce any law which shall abridge the privileges or immunities of citizens of the United States; nor shall any State deprive any person of life, liberty, or property, without due process of law; nor deny to any person within its jurisdiction the equal protection of the laws.
Yeah, we really need the government telling DBAs what to use as their primary key.
Any DBA who uses SSN as a primary key needs to be flogged with a CAT-5 cable. Privacy concerns aside, it's generally a bad idea to use any user-provided value as a PK because of the difficulty of guaranteeing uniqueness. People (intentionally or accidentally) enter bogus SSNs or refuse to give them, making it a poor choice as a required field, let alone a key.
If you have SSN as a required field with a unique constraint or index, you're setting yourself up for a denial of service attack -- User1 enters a bogus SSN which happens to belong to User2. Now User2 is effectively locked out of the system -- he can't enter his (valid) SSN because of the key constraint violation, so he either has to give up or give a bogus value as well.
I've seen about three times as many dead Fujitsu drives as other brands
Funny. I've got 2 ancient Fujitsu drives (a 1.2G and a 1.6G) still in service which have out-lived just about every other hard drive I've ever owned, which just goes to show you that personal experiences vary significantly.
I guess the moderator who called the parent "flamebait" is living in some strange parallel universe where King George received MORE votes than his opponent.
Ever consider that the reason the foreign students you met were so bright was because they were ATYPICAL, that the reason they went overseas to study was because they were among the best of the best in their countries?
they can be labeled as beginners now that you're experienced
And who's going to supervise these beginners? Who's going to train them? How are you going to retain them once they get some experience and start getting other job offers?
Knowledge workers (like programmers) are not interchangable commidity parts. You're paying them as much for their ability to think and solve problems moreso then you are for their mastery of specific skills. You have to invest time & money up front to get them to learn *your* business and to get them integrated into the organization so they're actually productive.
What (smart) companies are beginning to realize hiring smart & talented (hence expensive) engineers is more cost-effective in the long run than hiring cheap code monkeys to do the same work. If you have 3 uber-hackers making $100K each, they can probably produce better software in less time than a team of 10 code monkeys each making $30K. The savings of hiring a less-talented person is offset by the fact that you have to hire more of them to do the same job, and even then the quality of their work is not the same and they require more supervision.
I forgot to mention that we're preparing (high-horse alert!) students for life through a process of "education"
So the problem isn't the game itself, but rather the fact that your students lack the self-discipline to do what they have to do instead of what the want to do.
I can see how it's all the game's fault that the parents and teachers have failed to develop the kids self-discipline and time management skills.
News flash: learning how to deal with distractions and prioritize activities is an essential part of the educational process.
Yet it seems that the developers would demand a price in the range of 612 million
RTFA. The 612M figure is an ESTIMATE of what it would cost to DUPLICATE the 2.6 kernel using traditional software development methods. And it's probably a pretty reasonable estimate. Developing good complex software is HARD and EXPENSIVE.
"you ask a database for "all entries where field X is not equal to 47" it won't return any of those where field X is null because instead of saying "Null doesn't equal 47", the value "null" is deemed not to be comparable with any non-null field."
The FA is F'ed.
select * from foo where X is not null and X != 47
or
select * from foo where isnull(X,0) != 47
What's the problem with that?
Simply put, a null in any part of an expression renders the entire expression null. What's the value of (69 + null)? It's not 69, it's null. So what's the value of (null = null)? It's not true, it's not false, it's NULL! Once you wrap your brain around that concept, nulls won't give you any more problems.
Nulls get a bad rap because non-database programmers don't understand them and therefore misuse them. SQL is a very different language than most programmers are used to using. SQL is a functional language -- you tell it WHAT you want it to do, not HOW you want it to do it. It is also set-based, which can be confusing to someone who's used to using an iterative approach. This doesn't make it "good" or "bad", it just makes it different. It's a specialized tool for a specific job. As with any language, it takes effort to master SQL. Yes, SQL does have warts; but name me one language that DOESN'T have warts.
There are so many embedded applications that do just fine with 8-bit controllers that there is no reason they should dissapear just because something more powerful comes along.
Manufacturers are not stupid, therefore I'd be shocked if the 32-bit uC's are not backward-compatible with the older 8-bit models. Not just code-level backward compatibility, but pin-level backward compatibility too.
The main cost in a chip is the design, as you've noticed. Once you've masked out the die, it doesn't cost significantly more to fab a 32-bit chip as it does to fab an 8-bit chip. A 32-bit core implies that they're using a more modern process, so it's likely that they can now make a more powerful uC which uses less power & generates less heat than the previous generation.
Ah yes, the 83 Cutlass... by all accounts, the worst car GM ever built. I had the misfortune of owning one. It never went flying dutchman on me, although I'd heard about the problem. Mine had just the opposite problem, actually -- the engine would cut out for no F*ing reason whatsoever.
Slashdot Mirror
I assumed from the user@localhost in the error message that the DB was running on the same box as the web server. I assumed... my mistake
While you may not INTENTIONALLY give users the capability to run ad-hoc SQL, you've UNINTENTIONALLY done just that. The design you're using is (at least potentially) vulnerable to a SQL injection attack. An attacker who compromized the web server or found an exploitable bug in one of your forms would then have full control over the database server as well. The reason for using stored procedures is that this give you an additional access control mechanism to the database. SPs also give you the ability to control access at the row level, whereas native SQL security only lets you controll access at the table or column level.
In a safe design, the webuser db account does not have any select/insert/update/delete permissions on any of the tables directly - all they have is execute permission on the minimal set of stored procedures they need to use the system. This is known as the principle of least privilidge, a basic tenet of secure design.
Stored procedures (at least in Transact-SQL) work along the same basic lines as SUID scripts in Unix -- they run with the rights of their owner, not the executing user's rights. This way a user can perform operations against the database that they otherwise wouldn't have permission to do. This ensures that even if an attacker is able to mount a SQL injection attack, they won't have permission to do anything to the database that they wouldn't be able to do using the authorized interface.
I can see your point about error reporting, however, you need to be aware that it's a security hole. The posted error gives me enough information to plan a SQL injection attack against your system. Also, from a usability standpoint this kind of error reporting sucks -- that message is going to look like gibberish to a non-programmer. The end user needs error messages he can understand. You should by all means write that message to a log file, but don't show it to the user!
You have to know how to evaluate different technologies and pick the tool which is most appropriate for the task at hand. Only an amateur just goes with what he knows or what satisfies his political agenda.
You have to know how to design and configure your infrastructure so that it is secure and reliable. You have to know how to calculate anticipated load and how to do capacity planning. You have to know how to test your application -- both functional testing and stress testing. You have to know how to DESIGN an entire system before you jump in and start hacking code.
In other words, you need to act like a professional software engineer, not an amateur code monkey.
- You NEVER spit a raw error message back to an untrusted user, you write it to a (protected) log file. You're leaking information that an attacker can use to compromise the system. The user doesn't need that information, the developer does.
- You NEVER give an untrusted user permission to run arbitrary ad-hoc SQL statements against your database -- that's what Stored Procedures are for. If only know how to use a toy database which doesn't support stored procedures then you have no business whatsoever building trustworthy Enterprise applications.
- You NEVER put your database server and your web server on the same box in a production enviornment. That's just incredibly stupid in terms of both security and scalability.
Do yourself a favor and hire a real systems engineer with real-world experience designing secure, scalable, and reliable mission-critical systems; not some pathetic geek clown who "knows" php + mysql from putting together his 20-hit-per-day Blog server.When will people learn that MySQL, while a useful toy, just can't compare to a real Enterprise-grade database running on real Enterprise-grade hardware?
Not all tasks are CPU-Bound. Indeed, most common server-side business tasks (web, email, database) are I/O bound -- either on the disk side or on the network side. My personal experience has been that Linux is significantly more efficient when it comes to pushing big chunks of data around, and it tends to stay more responsive under heavy load than Windows.
Remember that game consoles are basically loss leaders -- they are sold at or below costs, with the profit coming from game sales and licensing fees. If you want to sell a game title for a given console, you have to fork over a hefty up-front fee as well as sizable percentage of the gross.
- Any performance improvement you get from having a highly-optimized driver is typically swallowed up by the general inefficiency of Windows itself.
- While the hardware vendor's coders may know their hardware, they don't (and CAN'T, due to it's closed nature) know the Windows internals and how their code will interact with Windows, hence the need for Microsoft to certify the drivers. IME, A *HUGE* number of BSOD errors (perhaps even the majority) are due to misbehaving or buggy vendor-supplied drivers.
The only place Linux falls behind is support for bleeding-edge hardware. This generally isn't a problem for me as I rarely if ever buy leading edge hardware due to it's lousy price/performance ratio. One or two steps back from top-of-the-line usually gives you >90% of the performance for 50% of the price.If you have SSN as a required field with a unique constraint or index, you're setting yourself up for a denial of service attack -- User1 enters a bogus SSN which happens to belong to User2. Now User2 is effectively locked out of the system -- he can't enter his (valid) SSN because of the key constraint violation, so he either has to give up or give a bogus value as well.
I guess the moderator who called the parent "flamebait" is living in some strange parallel universe where King George received MORE votes than his opponent.
Ever consider that the reason the foreign students you met were so bright was because they were ATYPICAL, that the reason they went overseas to study was because they were among the best of the best in their countries?
Knowledge workers (like programmers) are not interchangable commidity parts. You're paying them as much for their ability to think and solve problems moreso then you are for their mastery of specific skills. You have to invest time & money up front to get them to learn *your* business and to get them integrated into the organization so they're actually productive.
What (smart) companies are beginning to realize hiring smart & talented (hence expensive) engineers is more cost-effective in the long run than hiring cheap code monkeys to do the same work. If you have 3 uber-hackers making $100K each, they can probably produce better software in less time than a team of 10 code monkeys each making $30K. The savings of hiring a less-talented person is offset by the fact that you have to hire more of them to do the same job, and even then the quality of their work is not the same and they require more supervision.
I can see how it's all the game's fault that the parents and teachers have failed to develop the kids self-discipline and time management skills. News flash: learning how to deal with distractions and prioritize activities is an essential part of the educational process.
Simply put, a null in any part of an expression renders the entire expression null. What's the value of (69 + null)? It's not 69, it's null. So what's the value of (null = null)? It's not true, it's not false, it's NULL! Once you wrap your brain around that concept, nulls won't give you any more problems.
Nulls get a bad rap because non-database programmers don't understand them and therefore misuse them. SQL is a very different language than most programmers are used to using. SQL is a functional language -- you tell it WHAT you want it to do, not HOW you want it to do it. It is also set-based, which can be confusing to someone who's used to using an iterative approach. This doesn't make it "good" or "bad", it just makes it different. It's a specialized tool for a specific job. As with any language, it takes effort to master SQL. Yes, SQL does have warts; but name me one language that DOESN'T have warts.
The main cost in a chip is the design, as you've noticed. Once you've masked out the die, it doesn't cost significantly more to fab a 32-bit chip as it does to fab an 8-bit chip. A 32-bit core implies that they're using a more modern process, so it's likely that they can now make a more powerful uC which uses less power & generates less heat than the previous generation.
Ah yes, the 83 Cutlass... by all accounts, the worst car GM ever built. I had the misfortune of owning one. It never went flying dutchman on me, although I'd heard about the problem. Mine had just the opposite problem, actually -- the engine would cut out for no F*ing reason whatsoever.