Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Books Media Programming IT Technology

Secure Programming 360

Posted by michael from the self-promotion dept.
viega writes "Matt Messier and I have just launched a secure programming web site. While this site does support our new book The Secure Programming Cookbook for C and C++ , it also serves as a thorough resource for developers. It has numerous links to articles and other topical resources, new recipes that demonstrate secure programming techniques a large glossary and the obligatory web log. We accept outside submissions, and will reward the best recipe submission each month-- O'Reilly will publish it on the O'Reilly Network web site and will give the author a free book. There's already a decent amount of new content, including recipes on avoiding malloc()/new-related integer overflows, watching out for security problems in API differences and issues when truncating data. There's also an RSS feed for the web log."
This discussion has been archived. No new comments can be posted.

Secure Programming More

Secure Programming

Comments Filter:

  • Run-on sentence time (Score:5, Insightful)

    by mao che minh ( 611166 ) * on Sunday September 14, 2003 @11:03PM (#6961162) Journal
    Ten bucks says that this endeavor will go widely unnoticed by 90% of developers. Now I'm just a lowly IT worker, managing web servers and crawling under desks, but I do know that 95% of the developers in corporate America do not read Slashdot, and 95% of the ones that do are so intimately involved with Microsoft or Microsoft dependant technologies that this book/article/section/endeavor won't mean a damn. And before the trolls bark: YES, Microsoft = less security in development. Not by design - hardly - but rather because if a developer is working on a project that is Microsoft centric from the ground up, he/she is likely working on a time table set by some PHB a hundred miles away, and has been working on such projects for years, and has long since given up on making good, secure code, and rather coding whatever keeps his/her salary.

    Once you have worked 50 hours a week in a corporate setting for 5 years as a developer (2 years) and a run-of-the-mill network/system/any-god-damn-thing-they-can-get-you -to administer(4 years, you will understand.

    • Pay up.

      With not quite a million slashdot anonymous cowards, that Bureau of Labor Statistic [bls.gov] makes for more than all the software developers, I&T guys, database report wizards and embedded software engineers by twice here in U.S of A (not to mention outside world).

      Yes, you may be a lowly I&T worker; but you probably should not be worthy of posting ludicrous assumptions at Slashdot.

      And Ah, 95% of slashdot readers are Microsoft involved? Mmmmm. I put money down that this is closer to 85% or less th

    • Unfortynately - you are correct, period ! Just dont blame MS too much - they are bad but... As an example we do develope for public safety and have absolytely no guidlines or methods for safe software. Our management thinks that application level encryption is enough and safe - go figure. Makes me wonder - after 30 years in network security.. have a nice day.

    • Re:Run-on sentence time (Score:5, Insightful)

      by JaredOfEuropa ( 526365 ) on Monday September 15, 2003 @03:50AM (#6962139) Journal
      Ten bucks says that this endeavor will go widely unnoticed by 90% of developers.
      Sadly, you may be right.
      95% of the ones that do are so intimately involved with Microsoft or Microsoft dependant technologies that this book/article/section/endeavor won't mean a damn.
      What?! It is precisely because of the flaws of most modern operating systems that do not protect you from sloppy programming, that programmers need to be aware of secure programming methods. It's not just Windows either; Unix/Linux does not protect a programmer from, say, buffer overruns either. All programmers need to be aware of such flaws, and work around them.

      Programming securely does not have to cost you a lot of time either. Take the SafeStr library mentioned on the website for instance... a string library that can be used as replacement for the standard C string functions, a notorious source of buffer overruns and bugs. Using this library instead of the standard functions will cost little or no extra time.

      Programming securely is just like other good programming practices. Generally they do not cost extra time, they save time. It does take time to learn these practices, and that's where the responsibility of each programmer comes in. Take the time to learn good programming practices and get used to them, stay abreast of new developments, and above all train and encourage your junior team members to use these methods as well.

      The team that fails to adhere to good programming practices will turn out unstable and insecure software. Where do you think the bugs in Microsoft products come from? Tight timelines? Perhaps... but a great many of the bugs I come across are generally the result of a sloppy programmer, tight deadlines or no.

  • Good idea (Score:5, Interesting)

    by ljavelin ( 41345 ) on Sunday September 14, 2003 @11:05PM (#6961169)
    It's a good idea to have resources that are committed to security. Although some will claim that languages such as Java or C# prevent security issues, this is simply not true - there are many avenues to building security weaknesses... and those that think they're safe merely by using a particular programming language are in for a nasty surprise.

    Of course, a web site and a few books won't prevent security issues - but the more it gets the word out about good programming practices, the better!

    ---
    Herb Chambers - where my nightmare came true!

    • Re:Good idea (Score:3, Interesting)

      by Monkey Badass ( 447530 )
      Of course, a web site and a few books won't prevent security issues - but the more it gets the word out about good programming practices, the better!

      I agree. Cookie-cutter methods don't teach good secure coding practices. What we really need are more books that discuss how to address security throughout the life of software, beginning at its design. It's kind of sad that even after years of acknowledging this need, there are still only a handful of such books available. This kind of knowledge also would
      • There are several books out there that try to teach secure programming by relating it to good software engineering principles. The problem is, you can say things like "use encryption" all you want, but if you don't get far more concrete than that, people are going to get it wrong over and over again.

        If you look at the book, while there are indeed plenty of pieces of code people can just use, we thoroughly discuss design and implementation issues for each of the examples we give. That is, we're covering

    • > and those that think they're safe merely by using a particular programming language are in for a nasty surprise.

      That's true, of course, but nonetheless languages make a huge difference.

      In applications, buffer overflows, along with (recently) integer overflows, double-free bugs, and printf formatting bugs, are the most common source of exploitable holes by far. (Case in point: the MySQL buffer overflow currently on slashdot's main page, the several recent RPC vulnerabilities in XP, the recent OpenBSD

  • Warding off the inevitable "switch to Java" commen (Score:5, Insightful)

    by sco08y ( 615665 ) on Sunday September 14, 2003 @11:06PM (#6961178)
    If you RTFA, or even just GATFA (glance at) you'll notice that the book has info on:

    Random numbers

    Input validation

    Cryptography (e.g. ssh)

    Buffer overruns are just one kind of problem you need to deal with when writing secure code. There are also DOS attacks and information theft. Even with Java, it can be quite challenging to ensure that data is properly encrypted and authenticated, and you still need to worry about permissions in the file system.

    And let's not even dredge up the standard "why can't you just rewrite 100s of 1000s of lines of working C++ code in Java?" inanity.

  • I'd love to read the site, but ... (Score:4, Funny)

    by russh347 ( 316870 ) on Sunday September 14, 2003 @11:08PM (#6961191)
    I won't given the color scheme.

  • Secure programming FAQ (Score:5, Informative)

    by SystematicPsycho ( 456042 ) on Sunday September 14, 2003 @11:18PM (#6961244)
    Or for a quick and free guide, you can download the secure programming faq from one of the oldest websites on the internet-
    Securing Programming FAQ [mit.edu]
    --

  • I blame colleges (Score:3, Troll)

    by Amsterdam Vallon ( 639622 ) <amsterdamvallon2003@yahoo.com> on Sunday September 14, 2003 @11:19PM (#6961250) Homepage
    These degrees are handed out like toilet paper these days.

    Let's teach future American programmers proper security before they graduate and start writing professional software.

    There's no excuse for the fact that in order to write good, clean, secure code, our youngsters have to visit websites like secureprogramming.com in order to just get by.

    What a disgrace.

    • Re:I blame colleges (Score:5, Insightful)

      by metallicagoaltender ( 187235 ) on Sunday September 14, 2003 @11:30PM (#6961313) Homepage
      Blaming colleges is a complete copout - if colleges aren't teaching the proper skills, then employers should be rejecting applicants with inadequate skills.

      The fact is, most companies couldn't give half a shit about security on a day-to-day basis, and therefore don't really care if people fresh out of college have a clue about secure programming, or even security in general.

      The goal of college, in the context of our current society, is to prepare students to get a job - if employers aren't demanding it, then people aren't going to expect it to be part of a college curriculum.

      Don't get me wrong, I fully agree it should be a core part of computer education right from the start, but until the technology industry recognizes it as a day-to-day need (other than the 2 weeks after you've been hacked), it won't be considered an important part of the educational process.

      • I blame porridge (Score:2, Interesting)

        by segment ( 695309 )
        Blaming colleges is a complete copout - if colleges aren't teaching the proper skills, then employers should be rejecting applicants with inadequate skills.

        Agreed. Most of the companies I've been at of course hire college grads I mean who wouldn't, but most of the time it's those of us without degrees who've actually DTFW (done the fscking work) who end up making the big bucks even if it's only temporarily. This is not to say that a college grad isn't skilled hell most would probably clean the floor with

      • Re:I blame colleges (Score:2, Interesting)

        by Ichijo ( 607641 )

        The goal of college, in the context of our current society, is to prepare students to get a job - if employers aren't demanding it, then people aren't going to expect it to be part of a college curriculum.

        I see this as a chicken-and-egg problem. Employers don't understand the importance of secure programming because it isn't taught in college. The only other way to learn is by experience, but that's the hard way.

        There's really no excuse for teaching poor programming skills (or not teaching good progra

      • Does the industry want CS graduates who can only write hello world programs to be programmers?

        Maybe that may be a slight exaguaration. But they learn mathmatics and physics, english, history or other humanities, and maybe 2 or 3 courses with real programming while the rest is theory and calculus.

        The industry response was well lets look at India. These students there only focus on programming and not going to school and work for a 1/4th of the price!

      • Why is the goal of college to prepare students for job? That sounds more like a trade school. College should be for the pursuit of academics.
    • As someone who occassionally hires college graduates, they have a LOT more to fix before teaching people secure programming (although that would be great!). How about a graduate who can tell me the difference between a development environment and a production environment? Or is even aware of the concept of a production environment? What they teach in University seems to have such limited applicability in the real world as to be almost useless. I hate hiring graduates, complete pain in the rear for the first

      • Re:I blame colleges (Score:4, Insightful)

        by whereiswaldo ( 459052 ) on Sunday September 14, 2003 @11:57PM (#6961437) Journal
        How about a graduate who can tell me the difference between a development environment and a production environment?

        Also:

        - the importance of taking the time to do something right the first time as much as possible, instead of always the tiresome updates and tweaks.

        - what version control software is and how it is essential to team development (hell, you'd be surprised how many senior programmers don't know about it or use it).

        - how to take ownership of a task and see it through, not blaming someone else.

        - how to keep busy when the current task is blocked. Find another task, stay busy.

        - how to use your own head, and not ask questions about every single thing. If I have to give guidance on what colour your label should be, I might as well do the task myself.

        - common design patterns and practical applications of them.

        - performance optimization techniques, and why developing everything on a quad Xeon with gigabit ethernet is not always a good idea.

        - how calling in sick every week is not acceptable in the real world (not at most places, anyway).

        - how good organization techniques can save you a lot of time and keep you on target.

        - error handling code should be hilighted more. Books always seem to omit error handling, and that's what students learn from. That leads to really buggy code.

    • Re:I blame colleges (Score:2, Interesting)

      by mse61 ( 678636 )
      Speaking as a current CS student at a "major" university in the Midwest, I can honestly say that there is a HUGE lack of good programming practices taught. From the beginning you are taught to write code that is potentially buggy at best. I believe that it stems from the fact that a majority of people who are entering CS programs had little interaction with coding before their studies begin. It takes nearly 3 semesters of studies before the student is capable of writing correct, basic C++ code. By that
    • These degrees are handed out like toilet paper these days.
      Dude, that wasn't a university you spent four years in, it was a men's room. Oh, and that "Dean's Honor Roll" wasn't an award.
    • Let's teach future American programmers proper security before they graduate and start writing professional software.

      Hmmm. You mean that:
      Problem
      Integer overflows can lead to allocating too little memory, which can often result in an exploitable buffer overflow.

      Solution
      Before each memory allocation, be sure to check the size you're allocating, to make sure it really is big enough to do what you need.

      Should make you respond with 'Well, DUH!', before you get on the job?

      I've no idea what 'to be' prog
      • The solution may be obvious once you understand the problem, but the problem itself is incredibly non-obvious to most people who just go about allocating memory happily without ever thinking too deeply about the implications. Most developers are far more worried about getting the feature of the day working to "waste" a lot of cognitive effort on such things.

  • the first rule of secure programming club is (Score:3, Interesting)

    by Anonymous Coward on Sunday September 14, 2003 @11:21PM (#6961260)
    use a language that was specifically designed with security in mind
    like say, Ada

    oh yeah, let the negative moderation begin
    because programmer can't stand being held by the hand
    too big ego
    • really why not?

      Why is C or C++ some sort of a sacred cow. MS is throwing C away and going with C# why isn't the rest of the world throwing C away and going with Java or Python, or Eiffel or Lisp or whatever.

      Write in python and then rewrite the critical sections in C if you must. You'll still be more productive in the long run.
    • There have been architectures (eg Burroughs etc) that had most exploits designed out back when diskette rhymed with biscuit. Good languages (e.g. Ada and Modula) go way back.

      Right now, the most interesting of these better languages looks to be Cyclone (from Cornell) which has some chance of success because it is based on C. Certainly(?), next genration versions of C and C++ ought to prevent such problems unless the programmer explicitly permits them.


    • Quoting Bjarne Stroustrup when some moron tried to flame him for C++'s perceived lack of security, "I assume that a sufficiently skilled [cracker] will be able to do anything not explicitly forbidden by the hardware." (Emphasis mine.)

      So, the second rule is, recognize that most "levels of protection" and "access controls" in programming languages are there to help realize a clean design and facilitate debugging. NOT to enforce some kind of real-world security.

      • Just because I watched the movie the other night and can therefore quote entire reams from memory:

        • The 3rd rule of secure programming club is: some process yells SIGABRT, goes Z-state, taps out, the program is over.
        • 4th rule, only one major process to a sandbox.
        • 5th rule, only two sandboxes to a machine, fellas.
        • 6th rule, no telnetd, no ftpd.
        • 7th rule: debug sessions go on for as long as they have to.
        • And the 8th and final rule, if this is your first night at secure programming club, you will be 0wn3d.

  • Schneier's book considered harmful, or passe (Score:2, Informative)

    by Anonymous Coward
    Viega's site disses Schneier's book, which everyone else seems to regard as gospel. What's up with that? I like a juicy feud as much as the next guy.
    • In "Secrets and Lies," Schneider admitted that back when he wrote AP, he had too high of hopes for secure systems, and that his enthusiasm rubbed off on too many. Now people seem to think that you can just sprinkle an application with "encryption," and make it ironclad.

      Now his attitude is closer to "no system can ever be made secure, and that goes quadruple for systems which rely on the security practices of users." So Schneider himself isn't totally happy with AP.

  • Enhance Linux Operating System with BOSS (Score:3, Informative)

    by Dark Coder ( 66759 ) on Sunday September 14, 2003 @11:28PM (#6961306)
    IEEE Standards Associate, IEEE Information Assurance, IEEE Computer Society and IEEE Baseline Operating System Specification Working Group (BOSSWG [bosswg.org]) has initiated a call for definitions of a new operating systems intended to securely control nearly all aspect of the operating system (including root).

    Kinda sounds like Common Criteria, doesn't it; hopefully better.

  • Chapter 1 (Score:3, Funny)

    by Troll_Kamikaze ( 646926 ) on Sunday September 14, 2003 @11:28PM (#6961307)

    The Secure Programming Cookbook for C and C++, Chapter 1: Find an Alternative to C and C++.

    Seriously!

    • Re:Chapter 1 (Score:5, Informative)

      by viega ( 564643 ) <.gro.tsil. .ta. .ageiv.> on Sunday September 14, 2003 @11:51PM (#6961412) Homepage
      If only it were that easy! Most of the stuff in the book applies to any language under the sun, but the examples are in C. If the book were just about protecting against buffer overflows, then it would have been 50 pages instead of 800. There's a ton of hands-on material on how to use cryptography correctly in an application. It's still amazing to me that about 90% of the time I see SSL/TLS integrated into an application, it's used in ways that are grossly insecure (e.g., a man-in-the-middle attack is easy). Also, we cover things like how to prevent common input validation problems that happen in any language (e.g., SQL injection).

  • Do *what* to get your way to the top? (Score:3, Funny)

    by Anonymous Coward on Sunday September 14, 2003 @11:56PM (#6961433)
    "Now I'm just a lowly IT worker, managing web servers and crawling under desks"

    Crawling under desks? I know admin'ing IIS servers is bad enough because of the security problems, but to have to blow your boss to keep your job?

    Talk about getting fucked in both ends!
  • However, since I already own at least one of your books I'll check it out.
    • Even worse, my name is on a book that is pink. That's the reason for the current site color, BTW. Plus, I suppose we like torturing people at the same time we're trying to help them.

  • Interepreted languages help, but aren't a cure-all (Score:3, Insightful)

    by harikiri ( 211017 ) on Monday September 15, 2003 @12:31AM (#6961583)
    Buffer overflows are arguably the most common vulnerabilities that occur in the wild, which in turn indicates that most of the network services attacked are being written in C.

    Moving to interepreted languages mean that any dodgy user-supplied input will be detected at runtime, and will most likely result in some sort of a traceback (but no exploitable overflow).

    This however does not eliminate the remaining classes of vulnerabilities, relating to default configurations (username/passwords), poor encryption mechanisms, Denial of Service attacks (minimised due to most popular interpreted languages having their own garbage collection), and more.

    We need more developers to be putting on their black-hats, and looking at their code and wondering "what if I tried this? Could I break this code?".

  • 2 tips from the hood (Score:4, Interesting)

    by Anonymous Coward on Monday September 15, 2003 @12:33AM (#6961586)
    1. Create your own malloc/free new/delete heap. This heap should always have blocks of 0's interspersed throughout and a 1K walled block of 0's at the end of the heap. Any programming errors may result in garbage, but it won't result in injected code vulnerabilities.

    2. No direct DB access technology on your web service front ends. If your web UI code has SQL in it, you're doing something wrong. Your Web GUI should access an intermediate layer, instead. UI is notoriously easy to compromise, and the best way to make SQL injection attacks is to not have SQL directly beneath the button your users are playing with.

    • Re:2 tips from the hood (Score:4, Insightful)

      by shic ( 309152 ) on Monday September 15, 2003 @03:37AM (#6962115)
      While I agree with point 2, I can only say that point 1 is at best misguided nonsense and at worst a troll. If an attacker is able to overrun a buffer by a few bytes, then they are likely able to over-run by more than the 1K for which you've allowed. This technique is likely to give a false sense of confidence in an implementation as well as cause bloat - hence negating at least some of the advantages of the costly decision to implement at a low level permitting pointer arithmetic. There are much better ways to tackle such problems. In many cases C/C++ programmers should take a leaf from Java programmers and avoid pointer arithmetic in mainline code. It is trivial to code an ADT for arrays/strings in C, and C++ programmers should really consider STL containers. Only extremely low level code ever need directly manipulate pointers - and the cost of interacting at this level should be a moral obligation to show, using appropriate techniques such as pre-condition/post-condition inductive proofs, that buffer overruns are not possible.
      • Point 2 is bollocks as well.

        No SQL in your UI code? Sure, good move. Instead, move all your SQL into a back end and then call into it from your UI code. This goes as follows:

        1. You explain to your boss why all SQL should be done at the back end
        2. Your boss asks you whether it is really worth it to write six time as much code as one would imagine would berequired, just for security
        3. You say yes, trust me
        4. Someone breaks in anyway, because your lame middleware layer allows intrusion through it, and the intruder

        • Re:2 tips from the hood (Score:3, Informative)

          by shic ( 309152 )
          I see where you are coming from, however I felt more forgiving about the second point - maybe because the recommendation was more vague. The original poster (grammar aside) suggested that SQL generation should be separated from UI interaction - and this is, IMHO, usually a very good idea. No-one suggested "all SQL should be done at the back end;" Only you seem to think that six times the volume of code would necessarily be required for such a separation; only you suggest that a boss would disagree - and I

  • Variable input == DOS attack hole (Score:5, Insightful)

    by tjstork ( 137384 ) <todd@bandrowsky.gmail@com> on Monday September 15, 2003 @12:38AM (#6961612) Homepage Journal

    The problem is not the language, it's our style of programming.

    The whole reason that security issues have proliferated is our stubborn insistence on allowing for variable input. If all input and systems had hard wired capacities, then, there could be no denial of service attacks as program behavior would be bounded.

    Even C# and Java have DOS issues becuase of their unbounded nature. A program that reads an input stream and stuffs a link lists will be just as supsectible to denial of service attacks as any others.

    Some of us remember gravitating over to C from the old Pascal and FORTRAN and BASIC because of C's penchant for creating dynamic data structures. AS I look back on that era, I wonder if we didn't make something of a mistake.

    I wonder if we might borrow some of the practices from that ancient era, and use dynamic allocation as the exception, rather than rule. Programs should have fixed numbers of objects. Programs should have fixed input sizes and maximum capacities. String fields should always have a maximum, fixed, size.

    I should note that if we do have less variable length allocations, then, we less likely need programming languages that make variable length easy. A more conservative, almost retro programming technique could make for faster, more secure programming.
    • "I wonder if we might borrow some of the practices from that ancient era, and use dynamic allocation as the exception, rather than rule. Programs should have fixed numbers of objects. Programs should have fixed input sizes and maximum capacities. String fields should always have a maximum, fixed, size."

      You know what really bug me? Almost all languages have assertions and yet almost nobody uses them. If you are dealing with dynamic elements you should have pre and post conditions as assertions.
    • I should note that if we do have less variable length allocations, then, we less likely need programming languages that make variable length easy. A more conservative, almost retro programming technique could make for faster, more secure programming.

      This is my prefered method of programming - the problem lies in convincing users to accept arbitrary restrictions.

      The next best thing is to wrap all dynamic allocations in protected functions with paranoid checks built right in. Asserts are not enough, t

  • Strict mode for C++ (Score:3, Interesting)

    by Animats ( 122034 ) on Monday September 15, 2003 @12:40AM (#6961622) Homepage
    I once wrote Strict mode for C++ [animats.com], to address this issue. After much struggling, I concluded that backwards compatibility was tough enough that it wouldn't be accepted. With the recent hightened interest in security, it may be time to look at this again. (I'd make some changes to the syntax proposed there, though.)

    The basic idea is that everything is reference counted and subscript checked, but by doing some static analysis and type enforcement, most of the overhead for that is eliminated at compile time.

    About 95% of subscript checks can be optimized out without too much effort. An optimizing compiler that can hoist expressions out of loops and strength-reduce them can move most subscript checks out of inner loops. Reference counts require more language support, but they, too, can be optimized.

    As for pointer arithmetic, the solution is to use iterators, which are checkable, instead of pointers, which are not. Then optimize out the checks, as with subscript checks.

    I proposed that there be a way to designate C++ code as "strict", turning on the enforcement. Privileged programs should be 100% strict; others need not be.

    This is unlikely to happen, but it is technically possible.

  • My definition of "Secure Programming"... (Score:3, Funny)

    by solarrhino ( 581267 ) on Monday September 15, 2003 @12:41AM (#6961627) Homepage Journal
    ... is any programming job that can't be exported to India!

  • Vision of security isnt as bad as ./ make it (Score:3, Informative)

    by nighty5 ( 615965 ) on Monday September 15, 2003 @12:43AM (#6961630)
    Been in the security game for 10 years...

    From all these posts, it seems that all programmers don't have a clue about programming in a secure manner. I disagree, its just that times have changed.

    Surely, a few years ago this was the case. But certainly not as bad as now. Most PHB worth their weight usually know the security buzz words associated with an implementation are. If they don't give support to the developers to create a secure solution, they arent just lacking in security skills - they are lacking in overall management skills and an understanding of IT. Security has to be part of the overall process when in development, PHB's must invest *training* for programmers and develop standards to follow.

    Previous posters saying that it should be manditory for all post grads to have indepth security skills is down right short sighted. Security is a bottomless pit with many variables, a general subject can be taught. However, security can't stem strictly by programming practices. It is a collection of standards from all types, from the network, operating system to the application level. Not to mention the usual deal of people, process and technology.

    I've lost count of how many pen tests I've completed where the application design was rock solid, however they had a bad password on their admin portal.

    Nuff said....

    • IMHO, if your admin portal is susceptible to a practical password guessing attack, then there is generally far more that you could have done in your application design. One of the most obvious things to do is to reject any password that is easy to guess. But then there are plenty of good authentication schemes that don't use passwords at all, or use them only as one factor in a multi-factor system (such as a private key encrypted with a key derived from a password).

      I'd definitely say that it's impractic

  • no matter how good their secure coding is, they're no match for the ultimate overflow: the slashdot effect!
    • Yes, but not in the way you'd think. It wasn't bandwidth. The blog is being stupid and creating too many connections to the MySQL database, which eventually stops accepting more. Kicking MySQL is a reasonable stopgap measure.
  • I think I have spotted a small error in your otherwise excellent site.
    I checked out the HTML source and the problem seems to be in the spc.css file.
    There are several references to the value #BD3D89 and on the monitors I have here that value appears as a bright pink colour.

    Just thought I'd let you know.

  • Here's the full text (Score:4, Funny)

    by Anonymous Cowdog ( 154277 ) on Monday September 15, 2003 @01:09AM (#6961711) Journal
    Just in case the site gets slashdotted, here's a cut-n-paste of the home page. Whew, glad I was able to get in to get this:

    Internal Server Error
    The server encountered an internal error or misconfiguration and was unable to complete your request.

    Please contact the server administrator, mmessier@secureprogramming.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

    More information about this error may be available in the server error log.

    Apache/1.3.28 Server at www.secureprogramming.com Port 80

  • Articles like this don't make me want to use C/C++ (Score:3, Interesting)

    by GnuVince ( 623231 ) on Monday September 15, 2003 @07:21AM (#6962730)
    When I read articles in which they explain hundreds of coding techniques to make code secure, I really don't want to get involved with such languages. I am not a very good coder and for this reason, my favorite languages are Lisp, Python and O'Caml, all three languages have garbage collectors which frees me from a lot of work that has nothing to do with the task at hand. I know that I can't (and don't want to) deal with memory problems, so I use modern languages which think the programmer's time is more important than the computer's. Seriously, let's say I write an application to manage a little local computer store, why should I use C and potentially ship a lot of memory-related bugs with my app when I can use something like Lisp or Python or O'Caml which all are stable, complete and powerful languages in which that task would be easy and would result in a better application?
    • Seriously, let's say I write an application to manage a little local computer store, why should I use C and potentially ship a lot of memory-related bugs with my app when I can use something like Lisp or Python or O'Caml which all are stable, complete and powerful languages in which that task would be easy and would result in a better application?

      So you don't want to have memory allocation and pointer issues. Fine. That does not make your programs secure which is the end goal of secure programming in ____

Slashdot Top Deals

"Gotcha, you snot-necked weenies!" -- Post Bros. Comics

Close