Why I'm Giving up Coding...

LimeKID, the answer to is it worth the time is: YES. Someone's got to do the job.

That's a challenge - and challenges make life real.

If you've been doing that since 11 - you should be a pro by now ! Don't give up and keep it up!

 

I am a rather young developer, but my PHP skills have progressed very fast. I have found PHP to be a very secure language. My personal finding of insecure code is just not understanding where attacks be come into play in your script.

For example, EVERY PHP coders knows how to prevent SQL injections, excape XSS attacks, and so on. What developers might not notice initially are attacks like CSRF attacks.

( For anyone out there that is a PHP dev and do not know how to do any of the above or even know what a CSRF attack is, better do some reading and fast. )

I have found that the best exploits come in from sources you don't expect them. Possibilities are not escaping or cleaning Pagination information, not type casting, etc. For example, if you expect pagination results, check them for integer values and set them to intvals. If you allow an 'All' result, check for int first, if not int check that it is no more than three chars long (or just return the first three chars ).

A few things I always keep in mind when coding is :
Can anything in the current script be used improperly to perform a malicious or unwanted effect?
Can javascript be printed from the input supplied, whether from form inputs to input coming in from header or cookie information?
Are all my values what I expect them to be? Type cast EVERYTHING, try using sprintf in your queries ( see talkphp.net, they have a good tutorial on using sprint in queries ).
Know how to escape your data using mysql_real_escape_string, htmlspecialchars, and so on. Where strip_tags might fail, back it up and use regex to find and strip certain characters ( you can also try str_replace or strtr ).

You just have to keep in mind to pay extra attention to dynamic data, finding points of entry where data can be supplied or manipulated and ensure that they are the values you expect them to be.

 

My turn!

Damn straight, and isn't just for PHP.
Use Strict Is Not Perl.
In general, being able to read and maintain your code (or someone else's) makes security that much easier as well.

LimeKid, ever think of switching languages? There's a whole world out there : )

 

Which is exactly the type of thing checking HTTP_REFERRER prevents.

 

No not really, that can be spoofed as well. Some browsers even allow the user to change the headers sent out. I've found the best way to prevent CSRF attacks is on actions where users can say, delete their own articles or whatever, just give them a confirmation when they visit the page to do so. Since the attacker would send the user to a page which normally would delete their article ( delete.php?article_id=4 for example ), without it the article would be deleted and there's no way the attacker can force a user into the confirmation.

Some people use a token method, but I've read posts when attackers could easily get around this. I built a CMS where a user can delete their articles ( it really is just a request to delete ), but they way its setup up there is no $_GET to obtain the ID. I used Xajax to process the data via Ajax, it just calls a PHP function with the ID of the article passed as a parameter, and in addition added the confirmation just in case.

It's really hard to rely on things like HTTP_REFERRER and other super globals for security, as most often they can be forged ( even PHP_SELF can be forged ).

 

Quite true. You can easily do it via any language that lets you set the headers, or even via a telnet client connection on port 80.

Which is no reason not to still make the check. Yes, it can be spoofed, but if you are talking about a simple CSRF from a normal anchor on a page, which means no custom headers, that check stops it dead in it's tracks. HTTP_REFERRER is like the locks on a car - it's there to keep the honest people out.

See, that's why I don't send anything that critical as "get" data. I restrict get for anything that's output only. Edits of any sort should be passing as 'put' - including the command itself. "get" means you can spoof it in a simple anchor or even an image tag, "put" means they need a form with that action, a bit harder (though not impossible thanks to javascript and ajax).

Frankly, "delete.php?article_id=4" would be a really stupid way to write a delete function in the first place. Not only are we talking about openly passing the data as "Get", but the separate php to handle delete meaning you are either librarying out user verification or worse, hardcoding it into each file (early versions of phpBB anyone?)

But then I'm a believer in writing everything around one central index.php that handles all security aspects, then only includes the appropriate 'library' php files appropriate to the chosen action once it's certain everything is ok.

But then that's one of the common mistakes people make - having separate php files for each function that are called independantly - and if called directly have their own output handlers. To me library files should output nothing and just contain functions - if nothing else it lets you cut down on the number of globals. It's why I like how certain softwares use a simple 'define' - define a constant as one in your central index.php, and if you try to call other .php files in your application directly and that value isn't set, they 'die' with a warning message. Pass your variables as function paramenters keeping just the bare essentials as globals.

The article Stomme Poes linked to misses that about PHP, yes you can't predefine vars and typo's make new vars on the fly, but that's typical of EVERY non-Wirth family language (Usually fans of pascal/modula make fun of C for that very thing). The trick is that with PHP's automatically assuming all variables inside a function are local, to keep as much of your values inside the functions. If you need to pass anything critical as data, do it as function parameters so anyone doing a blind list of your globals through a code injection can't find anything 'worse' to exploit. (Of course mySQL login info still kind of pisses me off in that department - there's still NO good way not to use globals for that).

This is where a single central index.php also plays well - Your handful of globals get defined in the index.php and maybe the settings.php it calls, ANY other php files should have no globals of their own.

Of course, a central index.php for your whole application makes life a heck of a lot easier if (ok, when) you decide to use mod_rewrite to make 'friendly' URL's.

Most token methods last exactly how long it takes for an attacker to do a view source... So yeah, I'm not exactly sold on that one either the way most people handle it. They end up being about as secure as sessions...

The trick with tokens is to keep a list of them and invalidate them once 'used' and to set a time limit on them, invalidating them like you would a session. Tokens should be passed in the form, but only authorize certain actions or better, just one specific action - and when a valid action for a page is taken you invalidate all of them. This reduce the 'usefulness' of a specific token.

Of course a little javascript to invalidate all of them 'onunload' is a good idea too. NOT that you can rely on javascript for anything.

Rock on. That's pretty much what I just said - no $_GET, harder for them to pass a request.

... and there you lose me. Ajax is so reliant on client side scripting, something COMPLETELY insecure and so easy to hijack OR reverse engineer, I'm just not sold on it for doing anything security related... Relying on javascript in general is just asking for it to get pwned worse than your average turdpress install - AND it ties you to javascript which a lot of users refuse to use BECAUSE they don't trust it in terms of security. Scripting with no graceful fallback == /FAIL/.

Agreed, they are just the first steps. Again, like locks on a house or a car. They don't stop serious thiefs, but you still put them in and lock them.

 

Damn! you guys rock! seriously i have learn't so much from reading your posts its unbelievable! I know PHP but you guys are like gurus and I think I need to be more determined and focused on my coding. I think I am very impatient with coding. When somthing dosent work i feel like giving up and more times than not i do. Can i ask how you guys push through the hard times when your code cracks or when things just arent working? WHat are you working habits like? I used to work at night time but found that in the mornings my brain is fresh and things come to me a lot faster.

I have never been a big fan of Ajax. Some of the loop wholes in major sites leave me wondering if it is all worth it. For usability reasons it may be the future but for security reasons i'm not touching it for now.

Thanx again deathshadow's & xxKillswitch for your great posts, helped me alot.

 

I run into issues all the time where something doesn't work right or I just don't know a practical way to do something, then I just Google. That or check out pixel2life or other tutorial sites to see how others have incorporated similar tasks.

Before I started doing actual PHP work I tried to learn as much as I could about security and sanitizing data. It takes some time but once you understand attacks you can better understand how to prevent them. It's not so bad to be hacked or have your app broken when you have recent backups and logs to find where the attack occured.

I am somewhat of a slower coder in the sense that I am always reading back over the work I've done, asking myself certain questions along the way or looking for ways to improve the code. I try to read alot of tutorials and check out things I am not familiar with or have never used in my projects at the php manual. You can find alot of cool examples at the PHP manual as well, as they let users contribute scraps of code and whatnot.

Sticky with it and you will always be learning new things, better ways to do things, and you will learn more about security ( as long as I've been doing it I learned something new about security the other day ).

 

• Build in debugging to your code. I tend to have a log('EVENT NAME HERE') function so I can tell what point script execution gets to before a bug, and what the bug is.
• If you can't get something to work, come up with another way to do it, and use that until you can go back and work out why it isn't working. A lot of the time this can encourage you to use less efficient and safe techniques, but you have to go back and work it out to prevent that.
• Plan code thoroughly - flow charts etc. I'd hope you already do that, but the number of people who write 200 lines of php out of the blue tend to also be the ones who have problems with bugs and security. Planning makes things like this obvious from the outset - preventing the code rewrites that otherwise might be necessary.
  • I'm not saying to plan out echo 'Hello world'; though obviously...

Hope that helped

 

Appreciate your comment very much, thanx. I used to code right out of the blue when i first started, primarily because i didn't have any clear programming guidelines to follow and when you learn things by yourself you develop unconventional habits that can harm you in the long run. I'm going to start finding books and try to follow the php blogging world more closely. At this stage it looks like I haven't given up all hope in coding but i know its going to take a lot of work.

 

I have been programming computers for what is now approaching three decades. As such AT&T syntax languages are for me, old hat. PHP is the same dance, it's just a different tune.

I started out coding assembly, something that has served me very well over the years because I understand the underlying code used to make higher level languages function - this lets me very quickly dismiss 'dead end' technologies that are fat, bloated and nonsensical. (see XML databases and XSLT)... But over the years I've found one simple rule that let's me quickly cut the wheat from the chaff...

QUESTION EVERYTHING. Someone tells you something, THINK about it, does it make any sense? Too often you have people when it comes to web technologies who bob their head assuming the other person is 100% right because they don't understand a word of it... This is how "SEO" went from something that should be done inherently in clean semantic HTML has been transformed into a cottage industry of scammers, how fat bloated buggy CMS systems like Wordpress and Joomla along with rubbish WYSIWYGS like Dreamweaver and Frontpage have preyed on the ignorance of Joe Sixpack, and how sites like Dynamic Drive filled with rubbish javascripts that have no provision for graceful degredation or accessability continue to be copypasta'd daily by nubes into their sites.

Work on something else for a while and come back to it. Usually if I'm writing a custom CMS based site I have a standard 'framework' to which I can add the modules needed for the client - usually there are two or three modules and if I get stuck on one, I work on another one, get a good night's sleep and come back to it.

The problem with AJAX isn't so much it's usefulness, but it's overuse and abuse - the SAME problem as table based layouts and the use of flash for presentational items - and silverlight looks to be going down that same road. Think of it as just another tool, but understand it's limitations and it's risks.

What you are more likely encountering with people's code examples are simply programmers overthinking the solutions to the problem at hand. If you read my 'bad code, good code' post, look at the PHP example in there of bad code someone else wrote I ended up having to clean up. There's an old saying I learned back in the 70's that applies just as well today as it did then: The less code you use, the less there is to BREAK

ALWAYS ask yourself 'is there a simpler way of doing this' - and get intimately familiar with the language reference for whatever programming language you are using. Time and time again you'll see coders reinventing the wheel writing functions to do things we already have functions or even simple operators to do!

People have always talked about flowcharting, and I always found that to be a classroom thing that does NOT survive contact with real programming and if anything teaches BAD coding habits - typical of something taught by career educators; people with nothing but theoretical knowledge.

The reason I say this goes with the idea of simplifying your code - if you cannot see the logic flow of your written code clearly, you probably have rubbish habits for formatting, poorly thought out code with nonsensical evaluation, relying on things like premature exits, redundant comparisons, and no attempts at loop optimization. This is true of assembly, it's true of C, and it's true of PHP.

I also do NOT advocate an over-reliance on automated 'tools' to 'help' you be productive. Tools like prettyprint are great for taking someone else's rubbish code and formatting it into something comprehensable, but if you 'need' it on your own code then you are making rubbish. Editor tools like autocompletion (which for me have yet to auto-complete what I actually WANT and end up visually distracting), color code highlighting (yeah that acid trip is SO easy on the eyes and makes the text SO legible - NOT) - to me these are all sleazeball shortcuts that let people develop sloppy habits that inevitably bite them on the backside. (don't even get me STARTED about the complete ****ING RUBBISH known as dreamweaver - or anything else made by adobe for that matter)

Again, something I say a lot - proper code indentation, de-indentation and use of white space will save you more time and effort than a whole 1tb drive of 'tools'.

Which is not to say go nuts on the white-space. You see BAD overuse of whitespace in CSS all the time with people condensing all the properties to one line, and then putting spaces around EVERYTHING - making it impossible to tell a property from it's value at a glance. PHP developers often do this with variables too - throwing in so many spaces you cannot tell where one statement begins and another ends. This is particularly annoying around conditionals. COMPARISON operators should not be spaced, LOGICAL operators should be... That was the rule for two decades, suddenly your PHP and Java programmers come along and throw out 20 years of learning to make style guides that are illegible rubbish. (though that could just be my 20 years of looking at the older way of handling it)

A lot of the 'headaches' that plague new developers can be avoided if you learn the good 'habits' in the first place, and do not become so reliant on tools to try and 'make' your code good for you - because that NEVER works. Just save yourself the time and write good code in the first place. That's the biggest mistake nubes have is trying to 'simplify' their workload by relying on tools that just output rubbish outdated code, hide the underlying 'how it works' needed to actually understand what you are doing, and in the long run end up making MORE work or churning out unprofessional work.

There's a point at which you have to remember that this is WORK, you try to make it less work by taking shortcuts, trying to automate things computers aren't smart enough to do without handholding, and copypasta from twenty different sources code never meant to work together - don't be suprised when it leaves teeth impressions on yer kiester.

 

Ok... So understand the below things and I am sure you will able to devlop much secure applications:
Invalidated input parameters
User agent injection
HTTP response splitting
Execution before authentication
SQL injection
ORM injection
LDAP injection
Code injection
Command injection
SOAP injection
XMLRPC injection
DOM injection
JSON injection
Cross site scripting
Cross site request forgery
HTTP request smuggling
Path traversal
File include vulnerabilities
Buffer overflows
Default passwords
Weak password controls
Insecure credential passing
Broken Access control
Susceptibility to brute force
Weak encryptions
Un-trusted session data
Exposed session variable
Session forging / brute-forcing
Session hijacking
Session validation attacks
Insecure state management
Insecure configuration
Improper error handling
Insecure permissions
Hidden sub-domains
Insecure indexing
Temporary files
Hidden fields

 

Thanx again for your informative post deathshadow. Although i wasnt to sure on something you said...

What are good techniques on seeing the logic flow of your code before & during your work?

 

I totaly disagree with the topic starter.

Ofcource most beginners will make alot of security mistakes and that's logic! coz they don't know all the scripting/programming language functions and what to do with inputs.

The best way for a scripter/programmer is to check all values on their value. This can be easily done with regex wich all programming and scripting languages can do

For example: user registration with a couple of input fields (username, password, email address)

username may only contain a-zA-Z0-9[space]-_
password may only contain a-zA-Z0-9
email address may only contain a-zA-Z0-9-_@.

It's not much work, there are alot of free libraries to check your inputs for being valid! but most scripters/programmers rely (sorry for my poor english) on the language functions.

Like in PHP you can use the function FILTER_VAR wich have some filters for checking email addresses, site links and more. But i've experienced that the filter VALIDATE_EMAIL doens't work correctly and allow this:
email!!!!@email!!!!.com wich should not be validated

So best way is to validate your inputs every single time

in PHP you need to verify the following inputs (arrays)
$_GET
$_POST
$_SERVER
$_COOKIE

Hope this helps the topic starter to start scripting/programming again

 

The best techniques are knowing WHEN it's appropriate to offload a section of code to a function, and the proper use of formatting and comments.

Knowing when a function is appropriate or not is simpler than people think - are you going to do the exact same thing elsewhere in your code, or are you only doing this in one spot. If it's only going to be used once, don't use a function. As simple as that sounds, it's one of the most common mistakes you'll find - breaking out a section of code into a function when there was no good reason to, or the reverse, leaving major sections of code hardcoded into multiple separate functions when they could be condensed to a single codebase. Single codebase == less code == easier to maintain AND debug. Forum skins are among the worst offenders for this - they'll generate the same 'user info' box alongside each post and alongside PM's, but use two separate sets of code to generate that exact same info.

What is considered 'proper' indendation and formatting of code is subjective, but WAY more important than most give it credit. It's the simplest of things - if you are going to use tabs, use tabs, if you are going to use spaces, use spaces, do NOT mix and match as not everyone has their tab-stops set the same (back-room server geeks like three space, most die-hard coders like two space, most editors default to five, and some people use eight). You are best off using tabs and NOT spaces. Learn that most editors can indent and de-indent multiple lines at once. ALWAYS take the time to MANUALLY indent or de-indent logic blocks. As simple as it is, this is the most common mistake programmers make, usually resulting in a 'block' not being closed properly - be it a code block in curly brackets or block level tags. They then feed it into pretty print and if they are lucky it throws an error, otherwise it just makes a jumbled mess of nonsensical indentation. As I said if you need pretty print for your OWN code, you probably ****ed up. Simply indenting logic blocks makes the logic flow clearer AND prevents you from making mistakes - a little time spent with the tab key can save you more time debugging than rubbish like autoformatting/autocompletion ever could. I've repeatedly found that both autocompletion and autoformatting CAUSE more problems than they solve - yet coders still rely on them churning out fat bloated rubbish code.

The use of carriage returns can also REALLY help you, especially in white-space nuetral languages like PHP or HTML. Elements that are working on the same variable or set of variables should be together, while an extra carriage return between sets of different operations can greatly clarify code and make 'execution' blocks stand out. You'll also often see programmers obsess on cramming everything into one line when if they just put everything on it's own line it would be CLEARER. Complex conditionals when passing values to a function for example... Which is simpler to read, this:

spliceIntoMenu('topMenu',$settings['blogs']['menuTitle'],'/blogs',($settings['blogs']['menuPosition'] ? $settings['blogs']['menuPosition'] : -1));

Code (markup):

or this:

spliceIntoMenu(
	'topMenu',
	$settings['blogs']['menuTitle'],'/blogs',
	(
		$settings['blogs']['menuPosition'] ?
		$settings['blogs']['menuPosition'] : 
		-1
	)
);

Code (markup):

Identical code in terms of execution, but that latter is a HELL of a lot clearer what's going on since it's not a continuous jumbled mess. Among the worst offenders for this is the CSS some people use.

You can apply this approach to markup as well... I'll often see people combining ALL of the above 'issues' in their headers:

<link rel="alternate" type="application/rss+xml" title="Digital Point Forums RSS Feed" href="external.php?type=RSS2" />

Code (markup):

Word wrap makes it confusing, doesn't indent to show where the close is clearly, it's sloppy.

<link
	rel="alternate"
	type="application/rss+xml"
	title="Digital Point Forums RSS Feed"
	href="external.php?type=RSS2"
/>

Code (markup):

attribute=value each on their own line, the 'self closing' is on it's own line - just as if it were a block level element. You can clearly see at a glance which attributes are being defined, and therin can also at a glance tell which ones are missing (if any). That's what people miss most about condensing to a single line, you can't tell at a glance what's what! It's just one continuous poorly formatted blur.

What I'm talking about so far are the basics - basics that many new and old programmers alike skip, scoff at or call 'unneccessary'. The only reason to skip these basics is just being lazy.

For all that, one of the worst things you see in 'bad programming' is comments - as I said in my 'good code, bad code' topic (linked to in my signature) bad commenting is just wasted code - and an excellent article on that subject can be found on IBM's linux developer website:
http://www.ibm.com/developerworks/linux/library/l-clear-code/

One of the big things about commenting is that a lot of time it wouldn't even be neccessary if you just use variables that say WHAT they are... Get's worse when you comment the obvious.

/** Post Template API */
require_once(ABSPATH . WPINC . '/post-template.php');

Code (markup):

Really? Including a php file called post-template.php loads the post template API? Who'd have thunk it! Of course even dumber here are the two standard globals, one of which has a bit vague a name - especially since if you know what program that's from you realize that the WPINC variable is never used WITHOUT ABSPATH being added to it, so why aren't they just making WPINC=ABSPATH.WPINC; in the first place? Ends up in the same category as the 'and now we're finished' comment from that IBM website.

That said good comments can really help. You reach the end of a function put the function name in a comment before the close. It's de-indented so it should be the close, and putting it before gives you consistancy with how you SHOULD handle it in HTML (since putting it after in HTML can trip IE rendering bugs - YES, I said COMMENTS can cause IE rendering bugs!). In the case of a closing comment you don't need to say 'end functionname' - why not? Because you should have a closing bracket, that MEANS end you don't need to say it again! Mind you, if the function is only five to ten lines fitting onscreen by itslef, you probably don't need an ending comment, but it's DAMNED handy to have when a function reaches the hundred line or more mark.

When it comes to your own indentation, DOCUMENT it to build a style guide, or adopt an existing style guide, and FOLLOW IT ALL THE TIME.

... and don't waste your time deleting all your white-space to 'save bandwidth' or 'save diskspace' or any of that other rubbish. Instead concentrate on writing clear comprehensable code. While you see it in PHP a good deal, HTML is usually much worse for this - where you'll have people complaining about bandwidth use on their pages and stripping white-space to compensate for it, when it's their rubbish markup at fault. You'll see pages with only 2k of actual 'text' content bloated out with 20k of markup AFTER white-space stripping! Quite often you can guarantee the PHP under the hood is the same rubbish - thousands of lines of code spanning hundreds of files doing the job of hundreds of lines of code in tens of files. (here's a tip, if you have 3k of markup before you even open your BODY tag, you've probably got rubbish for code)

A final technique is to build a function and variable cross-reference. When you make a new function, write it in a plain text document, then every time you use it somewhere, write down what function or file is calling it. You make a global variable, write down each function that uses it. When you need to make a change to the function or variable you can quickly look at the list to see where else it's being used to consider the effects of those changes. This simple type of reference SHOULD be included with most any software, yet when I talk to programmers many of them have never even HEARD of building a cross-reference.

NONE of the above is earth shattering eye opening revalations set to give you an epiphany - it is simple techniques to avoid common mistakes in the first place... and it is with a measure of disgust that I've seen every new generation of programmers ignore these simple principles.

Though I have much more disgust for how a great many programs that prey on the ignorance of nubes are built ignoring everything I just said - like Wordpress, like Joomla, etc, etc... I shouldn't open up the source of a 'professional' program after only four years working in PHP and immediately go "What the **** is this ***otry!!!" - even with thirty years of writing software in other languages under my belt.

Let's just say there's a reason Wordpress won this years Pwnie for Mass Pwnage.

---------------------------

Apologies for the thread drift, but it is relevant - if you skip the basics you can make simple mistakes, and simple mistakes can very quickly turn into gaping security holes.

 

First comment on link one actually stats it:

Old article, dunno what PHP5 does. PHP6 will supposedly support namespacing and whatnot so that sounds promising.

ds++ exactly. I've seen it in other people's examples (where some Crusty comes along and replaces three functions with map, join, and sort or something) and have already run into it in my n00bie scripts. The way you avoid reinventing the wheel is by learning your language-- if you know all the words (or most of the words), you can use the right tool for the job instead of hammering another tool into shape.

Unless you're punching ducks.

 

I love Joebert's first post!

Don't give it in if it's something you really want to do.

My programming roots go back to assembler, cracking games (hacking) stripping protection. No matter how hard the companies would try to stop us we'd always manage it. We'd strip the protection from the games and re-distribute them with the ability to copy disks through DOS.

I guess I'm saying don't fret on the security too much because there will always be someone who can get around whatever you've put in place.

 

validate, validate and validate! A software developer needs to know how to write secure code. That is what development is. At the age of 21 you still have much to learn about good coding practices, and lots of time!

Don't give up just because an application of yours was hacked and you have made a fool of your self in front of a client. You are not the first, nor the last. Hundreds of web sites get hacked each day. That means hundreds of people that feel just as you do now.

Eventually you'll learn. It may however take a few years. I learned much quicker because I started with the security part and then the development I used to be a black hat myself, and now I switched sides and benefit from experience

 

if its about security.... the more experienced you are... the stronger you can develop.

in fact, we (programmer) can only reduce security vulnerability... we can't totally prevent it.