first website advice

[jawad]

Hi everybodyactually I have a problem with starting my first websiteany advice???thanks

[wirehopper]

Please post your code.

[jawad]

Please post your code.

dear wirehopper:I mean a general advice the problem is not in some code

[jeffman]

Don't use a WYSIWYG editor. If you do Windows, start off with Notepad++ ; if you do Mac, try TextWrangler.Use a strict doctype and write standards-compliant code. Validate it to make sure there are no errors. This will help make your pages look consistent in all browsers. (You need to take other steps too, but nothing works without a strict doctype.)Learn about CSS so your pages can all have the same look and feel.Don't learn from an old textbook that recommends using tables as a layout framework. No serious designer has used that technique for longer than half the web's existence.If you imagine working with a lot of pages and data that can be stored systematically, investigate a language like PHP and a database like MySQL. But do that after you master the basics of HTML and CSS.

[End User]

I agree with everything you said, with one exception. Sometimes I use tables for some of the basic layout. I may burn in the everlasting fires of Hades for it, but then I'm an old fogey and I've committed lots more awful sins than that. Am I a "serious designer"? I don't know...I've been building sites to earn my income for the last 10 years or so and haven't missed a house payment yet. I support my family from the revenue generated by my sites, and that's about as serious as it gets in my opinion. Personally I don't think most users care whether the sites they browse use tables or not, they just want to see and/or buy stuff. With that said, yes, for anyone who is just starting out, don't use tables. It's a bad habit and hard to break, just like smoking, using heroin, and shooting at random cars from the overpass near your house. Sometimes CSS can be frustrating to get just right but it's usually worth it in the long run. Remember though, you can always Give Up and Use Tables. :)Everything else you said was spot-on in my opinion. And I would also recommend:1) Start a "snippet" library of stuff you've built or coded. No need to solve the same problem over and over...if you've solved it, clip it out, stick it in the library and reuse it as often as needed. 2) Learn to use Google. Google is your friend, and it's a very, very good friend if you know how to use it. 3) Don't reinvent the wheel. Chances are whatever you're trying to do, 10,000 other coders have also tried to do it. Some of them have found good solutions and posted them on the web (see #2). 4) Take security seriously. Do NOT rely on simple-minded functions like magic_quotes or mysql_real_escape_string() to keep you safe. They won't. (Ask me how I know.) Learn how to sanitize your input data correctly and do it fanatically for every (and I mean EVERY) input value you use. 5) Expect that every form you use will be attacked mindlessly over and over by bots. It's just the way it is these days. Plan for it, guard against it, and always build some sort of interlock or usage limiting code into it. If you don't, you should expect some bot to hammer your site flat as it stupidly goes about its business throwing itself against your form(s) 20,000 times a day.

[chibineku]

4) Take security seriously. Do NOT rely on simple-minded functions like magic_quotes or mysql_real_escape_string() to keep you safe. They won't. (Ask me how I know.) Learn how to sanitize your input data correctly and do it fanatically for every (and I mean EVERY) input value you use.

How do you know?

[wirehopper]

I agree with End User - security is vital. I've cleaned up after many hacks. It costs time and money, and it's really frustrating.A server is a resource. Hackers use them to attack other machines, distribute 'warez', and other harmful or illegal content. They don't care who you are, or what the site does, in fact, many times, the attack comes from a 'bot.You wouldn't expect a basic contact form to be a hazard, but that's one of the most common things that is exploited, often to distribute spam. Check this out: http://botscout.com/It isn't just custom code, written by 'noobs' that gets hacked - powerful, popular web applications are vulnerable, too. You have to monitor the server, the stats, and the application. They need to be maintained and upgraded as necessary.Hacks can come from inside the server as well, especially on shared hosting accounts. File permssions are often your best protection against these. Avoid 777 and 666.My final advice for a site is to have a specific goal or objective. Offer something helpful or of value, and focus it. Don't expect to become wealthy with your first site.

[End User]

How do you know?

I know because I've seen loads and loads of clever attacks that mysql_real_escape_string() won't mitigate, and I've been the target of more than a few. Most of my sites are scanned and attacked daily by bots attempting to compromise various forms. The fact is that if you have a site on the web, it's under attack. Don't think for a moment that it isn't. The bots and people trying to get into your server don't necessarily want your content, they want your platform. They want to be able to serve malware, send spam, host phishing and 'pill' sites, store warez and child porn, launch attacks on other sites, and so on. Your content is usually of no interest to them. Your computing power is. If you want to see some good examples of why relying on mysql_real_escape_string() is a joke, take a look at http://ha.ckers.org/xss.html, the "XSS cheat sheet". Many of those examples will slide right through mysql_real_escape_string() without the slightest difficulty whatsoever. In short, if you rely on mysql_real_escape_string() it's just a matter of time until your site or server will be cracked and compromised.

[iwato]

I have a problem with starting my first website, any advice???

Hi, Jawad!The first thing you need to be clear about is what you hope to achieve with the knowledge that you gain while building your website. Website design and development can require very little knowledge with many constraints, or very much knowledge with an unlimited horizon. There is an important trade-off here that you learn as you go along.In short, you need to be clear about your long term objective, and then develop a knowledge strategy toward achieving that objective. With this in mind, why not tell us what your long term objective is?Roddy

[justsomeguy]

I know because I've seen loads and loads of clever attacks that mysql_real_escape_string() won't mitigate, and I've been the target of more than a few.

This is a little misleading. You're describing things like XSS attacks. Mysql_real_escape_string is not for stopping XSS attacks, it's for stopping SQL injection attacks, which it does (combined with functions like intval and floatval). It's one thing to say that mysql_real_escape_string will not protect against anything other than SQL injection attacks, and that it's not wise to rely on only that function for security, but it's another thing to claim that mysql_real_escape_string doesn't protect you at all. It does, it simply doesn't protect from every single kind of attack. There is no one method to protect against all attacks, you need to use different techniques to mitigate different attack vectors. You can use htmlentities, for example, to protect against XSS attacks, but htmlentities is also not going to protect against SQL injection attacks. You need to use several methods to deal with the different attacks.

[chibineku]

I always use a combination of intval and mysqli_real_escape_string or htmlspecialchars/htmlentities, so I ought to be set. I have tried various injections, and even knowing the exact structure and nature of my SQL queries and storage methods I still only get harmless input/output.

[wirehopper]

Where appropriate, validation provides excellent protection. If your script is expecting a numeric value, and you refuse anything other than digits within a range, you will be well protected - for that input.

[End User]

Well, yes and no. I should have been more explicit in exactly what I meant.You're absolutely right in that mysql_real_escape_string() can provide some protection. Sadly, I often see it portrayed or described as the solution to all sorts of things that it won't actually protect against (and I see this a lot, unfortunately). People ask about "guarding against hackers" and oftentimes the stock reply is something like "just use mysql_real_escape_string() and you'll be okay". From what I've seen on the http://ha.ckers.org/xss.html examples page, htmlentities() can be bypassed with tricks like multiple octal encoding, embedded nulls, and a few other techniques. It's possible to sneak a SQL injection attack past mysql_real_escape_string(), so (as you mention) it's necessary to use several methods to deal with different kinds of attacks. Even the PHP.net page says little about it- their main comment is that "This function must always (with few exceptions) be used to make data safe before sending a query to MySQL." To a lot of people that's going to sound like some sort of universal protection, and I wish they (PHP.net) would go into a little more detail about how it's not a panacea. I see a lot of newly-released scripts which have virtually no input screening or that rely primarily on mysql_real_escape_string() for protection. I think one of the most important things that new programmers (of any language) need to learn is how to sanitize and validate input data. It seems to be glossed over in a lot of places. In my opinion it's where 99% of the problems start, but few people seem to be familiar with it. One last thing- I never said that "mysql_real_escape_string doesn't protect you at all", what I said was "if you rely on mysql_real_escape_string() it's just a matter of time until your site or server will be cracked and compromised." And I still believe that's a valid statement.

This is a little misleading. You're describing things like XSS attacks. Mysql_real_escape_string is not for stopping XSS attacks, it's for stopping SQL injection attacks, which it does (combined with functions like intval and floatval). It's one thing to say that mysql_real_escape_string will not protect against anything other than SQL injection attacks, and that it's not wise to rely on only that function for security, but it's another thing to claim that mysql_real_escape_string doesn't protect you at all. It does, it simply doesn't protect from every single kind of attack. There is no one method to protect against all attacks, you need to use different techniques to mitigate different attack vectors. You can use htmlentities, for example, to protect against XSS attacks, but htmlentities is also not going to protect against SQL injection attacks. You need to use several methods to deal with the different attacks.

[jawad]

I appreciate all your repliesthank you all