Jump to content

scootstah

Staff Alumni
  • Posts

    3,858
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by scootstah

  1. Typically if I run into something like this and I am unfamiliar with the code base, I will do a full project text search to try to figure out where the HTML is coming from. In this case try searching for something like "form-row legal terms" and see if you find anything.
  2. You should take a screenshot of your everyday setup.
  3. I assume you are using CodeIgniter? By default form_error() places the error inside [tt<p></p>[/tt] tags. You can change these tags though, and define a CSS class. <?php echo form_error('passconf', '<p class="error"'); You can use the third parameter to close a tag other than <p>. <?php echo form_error('passconf', '<div class="error">', '</div>'); Or, you can set the error delimiters globally. $this->form_validation->set_error_delimiters('<div class="error"', '</div>'); Check the docs for more information.
  4. Do you mean it allows you to enter a username even if one exists? I'm not sure what you are using for a database layer, but I don't think $query would directly contain the number of rows. I would expect $query to be an object. So with the little code I have to work with I would say you need to do two things. 1) You need to check the actual number of rows returned and 2) you need to check if the rows returned are > (greater than) 0, not 1. As it stands if you have a single username already in the database it will allow another entry. Why? Because 1 is not greater than 1.
  5. I'm not sure about the first but the second one appears to attempt to inject a potentially malicious image into the page. The "image" could potentially execute code to do various bad things.
  6. Indeed, and making PHP accept session ID's from only cookies is one of them. Sure, but the circumstances are different. Allowing session ID's in the URL can be manipulated in a number of ways. For example if the site doesn't use SSL then every out-going link will potentially contain the session ID which can be found in the receiving sites HTTP referrer. It is much more difficult for a third party to read a user's cookie from another website, modern browsers prevent that. You'd need to explicitly send the cookie data from the original site to a third party site - like through an XSS attack, which is a lot easier to manage. Passing session ID's through the URL creates more problems than it solves. In fact, it doesn't even solve this problem - the client can still reset the session data.
  7. The is_unique() method expects that the standard database library is loaded. Do you have it loaded? If you don't want to do that you'll need to extend the form_validation class and write your own is_unique method using doctrine.
  8. The session id is, by default, stored in a cookie. Not the data. With a cookie, the time remaining is stored on the user's browser. The user can modify the time remaining to, ex., 0 seconds left. With a session, the time remaining is stored on the web server. The time can not be modified by the user, and thus is more secure. Once again if you delete the session cookie the session will be destroyed and all data in the session will become unset. Therefore if you set a session flag like $_SESSION['already_voted'] = true; and then you delete the session cookie, this data is unset and the session array will be empty. You cut out the part of my post that breaks this logic. Because that's a bad idea that can lead to session hijacking, so it's not a valid alternative. The only way to semi-reliably do what the OP wants is to have user accounts. You could use logic to make it so user's could only vote once, which means you would need multiple accounts to vote multiple times. Still possible, but more work. Other than that, it cannot be done reliably without punishing innocent users. You either block too many users, or don't block enough users.
  9. The session id is, by default, stored in a cookie. Not the data. With a cookie, the time remaining is stored on the user's browser. The user can modify the time remaining to, ex., 0 seconds left. With a session, the time remaining is stored on the web server. The time can not be modified by the user, and thus is more secure. Once again if you delete the session cookie the session will be destroyed and all data in the session will become unset. Therefore if you set a session flag like $_SESSION['already_voted'] = true; and then you delete the session cookie, this data is unset and the session array will be empty.
  10. The PHP session is stored as a cookie. If you delete the cookie, you destroy the session.
  11. The problem is that this sort of thing can't be fully prevented without penalizing innocent users. Making decisions based on a users IP is always not a very good solution, since there is no guarantee that a users IP is unique to that user, or that it will stay the same. Some user's IP changes frequently, other user's share the same IP (like people in a college or in office buildings). So if you simply store the user's IP and not let anyone else with that IP vote again, you're potentially disallowing anyone on the same network from voting. Yes, I will agree with you. But, storing data only through cookies is quite situational. Sometimes cookies just aren't secure enough. But restricting purely based on IP is sloppy and overly restrictive. I haven't looked a lot into the ability to save PHP sessions to a file/database, but perhaps that may work best in this scenario. A cookie isn't secure because it is data stored on the client's browser. A PHP session is a server-sided per-user key/value storage, though. Normally, they can't be trusted over a prolonged period because they don't last all that long - just long enough for the current session. But, PHP's session_set_save_handler may be able to remedy this, allowing the backend to store sessions upon deletion, instead of just permanently deleting them. But, as I said before, I am not all that experienced with the practice of saving/storing sessions, although it seems possible without too much hassle. So, if anyone has a better grasp of saving sessions, please don't hesitate to comment. Sessions use cookies, so if you think cookies are not enough then neither are sessions.
  12. I'm confused. You said the game was for jQuery, but ActionScript is Flash. Is the game written in Javascript or Actionscript? Either way, they wouldn't be able to encrypt their own values because they wouldn't have the encryption key.
  13. The problem is that this sort of thing can't be fully prevented without penalizing innocent users. Making decisions based on a users IP is always not a very good solution, since there is no guarantee that a users IP is unique to that user, or that it will stay the same. Some user's IP changes frequently, other user's share the same IP (like people in a college or in office buildings). So if you simply store the user's IP and not let anyone else with that IP vote again, you're potentially disallowing anyone on the same network from voting.
  14. You could probably encrypt the POST data, and obfuscate the Javascript. It's still beatable but it's better than plaintext.
  15. That is JSON. You'll need to decode it, which will turn it into an object. $json = json_decode($output); $api_url = "http://localhost/?access_token=" . $json->access_token;
  16. Are you using CodeIgniter? If so, you're doing something very wrong...you shouldn't have any output in that file.
  17. You could try Nearly Free Speech. For a very small, simple website they are pretty damn cheap. Anything that needs a lot of bandwidth/diskspace though isn't very good.
  18. As long as the video_id field is an integer.
  19. Put quotes around the variable. WHERE video_id = '$super' LIMIT 1 Also, don't stick user input into your database like that or you will be vulnerable to SQL injection. I don't know what you're using to connect to the database so I can't offer any specifics.
  20. The ladies must love you. *cough* Sorry... Anyway, if you want to run code on specific time intervals without a user executing it (viewing the page) then you'll have to use something like a cron job.
  21. Have you tried an IDE? I used to think a simple text editor was all I needed too, but then I tried an IDE. The only time I use a regular text editor now is just for real quick edits, or stuff that I don't want to make into a project in my IDE. IDE's tend to get in my way. Yeah, that's how I felt too. I have my Eclipse setup to be pretty minimal though. For example, the annoying help box that pops up with every keystroke is disabled. It only pops up if I want it to by hitting ctrl+space. Most of the time it is unneeded, though sometimes I need it to remember which order parameters go in in a function (since PHP seems to make that as illogical as possible). I mostly like it for automatic bracket/quote closing. I like the way Eclipse auto-indents too. It may seem silly but some editors have shoddy auto-indenting. Anyway, I like Eclipse because it gives me some of the advantages of an IDE but it doesn't hold my hand.
  22. Have you tried an IDE? I used to think a simple text editor was all I needed too, but then I tried an IDE. The only time I use a regular text editor now is just for real quick edits, or stuff that I don't want to make into a project in my IDE.
  23. Yep. And it was incoherent, to be honest. What it had to do with my Original Post is beyond me. You provide code when you ask a coding question, why would you not provide database information when you ask a database question? And yes, this is a database question. Database queries may be implemented in code but are independent from it. Having no samples to actually test, I have come up with this. I don't know if it's what you want or not: // Build query. $q2 = 'SELECT m.first_name, m.username, m.photo_name, m.photo_label, m.location, m.created_on, m.logged_in, m.last_activity, c.created_on, c.body, c.status, (SELECT COUNT(*) FROM comment WHERE member_id = m.id) AS post_count FROM member AS m INNER JOIN comment AS c ON m.id = c.member_id WHERE c.status="Approved" AND c.article_id=? ORDER BY c.created_on';
  24. It's not $_SERVER that is unsafe, it is certain indexes of $_SERVER, such as PHP_SELF which can be manipulated by the client to pose a potential XSS attack.
  25. Sometimes you may want to have things change in your overall layout depending on what page you are on. For example using menus which expand; you may want to expand the current page item.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.