i created script which will count child's div for some certain div with this command
$('#content').children().size()
by this count i know to fetch from 12 to 18 from mysql if this count is 12.
with firebug i can find out this count which will post to my script and i thought is there any way to increase this size to get more details from my database in some way?is it secure to pass such data from ajax?
2-can someone post data or simulate posting in any way?for example simulate data which will post by form like this data=2&foo=3&bar=4 and cheating on server?
check this link,it's can be useful
check for authentication and authorization
Encrypt or add salted hash checks to data exported to the browser for resubmission
treat any data received in the request as potentially dangerous
use HTTPS where its appropriate
transform data leaving your PHP using the right method for were its going (htmlentities, mysql_real_escape_string
transform data entering your script using the right method based on its origin (e.g. json_decode)
As per my comment, once more as answer.
'Safe' is relative. Basically AJAX is nothing but a plain HTTP request based on JavaScript. So it's not any more or less safe than one like that. To make it 'safe' you could use HTTPS to encrypt the connection. That way, you should be able to prevent injection and stuff. Regarding the cheating...if one really wants to, he can. The only thing you can do, is to check the parameters carefully and therefore detect irregularities. Maybe add a hidden checksum, which only allows for particular options.
Related
Is it safe to use $_POST for button action ?
for ex.
<button name="submit">Table A</button>
php (what my code here does is, if i click the button(Table A) the table A will appear then, in default is not viewable.)
if(isset($_POST['submit'])) {
<table>
code....
</table>
}
FOR MY QUESTION: is it safe ? to the attacker ? like xss, sql injection, or something ? I want an advice, to have more safer website. (or atleast safer from attackers)
It is safe provided you don't echo the output or use it unescaped within a SQL statement. Also your code should really be...
if(isset($_POST['submit'])) {
...
}
to avoid errors if it isn't set
Developer has always to sanitize and to validate the input he's getting from the request.
Depending on the purposes - you need either to enforce the sanitation or to make less cleaning (for example for DB you need to clean it up/escape additionally, for HTML output to make XSS protection, etc.)
You may read up on:
How to sanitize the input (POST/GET variables, referral, cookies, user agent, and other headers)
Cross-Site Request Forgery (CSRF) prevention;
additionally you may want to use Captcha or other protection from automatic submits, etc.
For your specific purposes, in the question itself - you are not using the value of $_POST['submit'] in any way, except checking of presence, so no additional validation is needed, it's fine like that.
Short answer
NO
POST variables are not 'safe' on their own.
Long Answer:
There are many issues around authenticating POSTed variables on your PHP script. The most well known is Cross Site Request Forgeries whereby the value is sent to your page but you have no idea where the value came from, or who sent it.
To counter this you need to set up single use unique keys to send and receive, typically using PHP SESSIONS or similar concepts that can not be touched by the end user.
The second issue is that you should never ever ever trust the contents of a POSTed variable. you need to fully escape the variable as well as ensuring that the variable is given absolutely minimum access to your code, so if it is a compromised value, it is hopefully cleaned and/or it can not harm your script.
Your Code:
Looking at your question in detail you suffer from CSRF (point 1, above) in that your PHP code has no idea if the submitted button came from the page your button exists on and therefore the PHP has no idea if the browser should see the contents of "Table A". (If everyone can see it, why hide it in the first place?)
There is also the factor your code could be used by a nefarious party to send many, many POSTed submits to the script, over a short space of time (100,000 over 2 seconds) causing a DOS attack, again due to there being no validation of where the POST came from and its implied authenticity.
Further points: You need to clarify what you deem as "safe", it is a very relative term.
You can use the button with POST. But make sure, you have validated the referrer URL of the action. Because someone may try to copy your form and submit in loop. This will down your site.
So you should check the referrer URL matches with your site URL.
Also always use form token to validate the form (Like captcha)
I am developing a site where I am sending parameters like ids by url. I have used urlencode and base64encode to encode the parameters.
My problem is that how can I prevent the users or hackers to play with url paramenters Or give access only if the parameter value is exist in database?
I have at least 2 and at most 5 parameter in url so is this feasible to check every parameter is exist in database on every page?
Thanks
You cannot stop users from playing with your QueryString.
You can only validate them in your script before you do anything with them.
This also applies to POSTed variables as well, they can be hacked almost as easily.
So Validate, validate, validate.
In general if you concern about internal data put them in a session variable. But remember always everything out there is evil. You alway have to check if any input contain SQL injections.
If you use session cookies make sure that hey are http only. So no JavaScript can copy the session cookies and if possible never put them in the url itself. It's quiet easy to copy the url and hijacking a existing session.
This depends a bit on what you are using the parameters for. If they are private and should not be accessible to other users, you should link the data to a specific user and deny access to everyone who isn't authenticated as the correct user.
Also, always remember to sanitize user inputs, which includes URL parameters. Use prepared statements when passing user inputs to a database and encode it before serving it back to other users.
The best I would to is to validate on server side for the user entered paramters. Also I would check if the requests originated from my site (XSS & CSRF). Transmitting data post would be good but provides minimal security IMHO.
Therefore, validate and authenticate the originating location to ensure that it does not come from an outside source
I'm wanting to pass data from one php page to another on click, and use that data in populating the linked page. At first I was going to use ajax to do this, but ran into trouble, and then realized it was as easy as placing the data in the href of the link.
My question is, is it safe to place the data directly in the href in this manner? I know that passing the data via the URL (which this ends up doing) is safe, but I heard somewhere (that I can't recall), that placing the data directly in the href of a link can cause problems with web-crawlers and the like.
Is this true? Is there anything else I should worry about in using this method? Or is this the best way for me to send data, unique to each link, to another page on click?
The PHP:
while($row = mysql_fetch_assoc($result_pag_data)) {
echo "<a target='_blank' href='secondary_imgs.php?imgId=".$row['imgId']."'></a>";
}
There should be no problems with web crawlers as they just follow the links.
There is however a potential security problem in that malicious users can address arbitrary rows in your table by altering the URL string. This may or may not be a problems depending on what the links point to.
If you need to restrict your data to particular users then this is not a good idea, otherwise, its simple and straightforward if it works for you then do it.
I think it's safe enough if you want to display some data, but never use get method to insert data, especially careful when it comes to sql. NEVER use get method to modify sql, if had to, validify the arguments first.
Be careful with post method too. In a word, never trust users, you never know.
It looks like it's safe since you're "only" querying an image with a specific id (that's all you're doing, right?). Just ask yourself if
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".
applies.
Neither passing data through URL, nor embedding it into href is safe.
That data can be seen by user, so you are not protecting your data from user.
That data can be modified by user, so you are not protecting your data from modification and your script from getting evil or misformed parameters.
So, if you are designing the system which is going to be run under strict protection in a friendly environment - it's OK to pass params through the URL (hovewer, note that URL string is limited to 4096 characters). If not - it depends on protection level you want.
The simpliest way is to use POST requests instead of GET. THis way you'll not protect your data from evildoers, but ordinary users will not have the ability neither see nor modify it. Anyway, it's a good idea to validate the input on the server always.
Define "safe".
Without knowing the the threat model is nor how the data is used it's impossible to answer.
Certainly there are very important differences between a GET and POST (but note that a POSTed for can still send GET variables via the action URL).
It's no less dangerous using a POST rather than GET to send data. Nor using a cookie. All can be modified at the client end.
If you're talking about CSRF, then there's lots of methods to prevent this - try Google for starters.
I want to validate a form without having to reload the entire page. I am using JavaScript at the moment, however this is massively insecure. To get round this, I want to use AJAX and a PHP script to validate the form. Does anyone know of any security risks this might have?
I also assume the AJAX method is far safer than vanilla JS, but I could be wrong?
They are exactly the same as the risks of validating with pure client side JavaScript. The only difference is that you are asking the server for some data as part of the process.
The user can override the JavaScript to submit the form no matter what the validation outcome is.
The only reason to use JavaScript at all when checking data for submission is to save the user time. If as part of that you want to do something such as asking the server if a username is taken while the user fills out the rest of the form, then great — that is quite a nice use of Ajax. Otherwise, using Ajax is pretty worthless.
If you want to do client side checking, then put all the logic you can for it on the client and avoid making HTTP requests. If you have things that can only be checked server side (because they are based on data, like the example with usernames that are already taken) then consider using Ajax for that. The client side check is the convenience check. Always do the security check server side and on the final submitted data.
Note that validating data that is actually submitted using Ajax is a different matter — since that is the final submitted data. It is doing Ajax validation as a precursor to the final submission that doesn't add any trust to the data.
All AJAX does is offload part of the process to the server, 'hidden' from the client (in the sense the functional handling of your data/variables is hidden). That said, you should be wary of the information being sent to the server, which can be captured or worse, duped. The difference with pure JS is that your functional handling is there for all to see, and potentially exploit.
Validation shouldnt need to be done server side unless you are validating DB content (i.e. uniqueness of a username etc). If you are simply validating whether something is an email, you can do this in JS, eg with a RegEx.
If you are validating DB data, make sure all DB queries variables which originate from sent (POST/GET) variables are escaped using mysql_real_escape_string to prevent SQL injection
You can validate data in AJAX as well as you can do it in pure JavaScript, but you have to re-validate it in your script after it receives the data.
Every client-side validation method can be avoided by sending POST request to your form target.
The main thing to bear in mind here is that when using AJAX you are essentially providing an interface to your database. For example, if you are checking for duplicate usernames (which you CANNOT do in javascript) or duplicate emails, so as to provide a message such as "this username is already in use ... please try another", you are providing an interface for a potential hacker to immediately check which usernames and/or emails are available. The security considerations are NOT the same as for javascript.
My advice to you on this topic is (1) Use parameterised queries to access database as someone has already suggested. (2) Implement a delay on the ajax .php page - the length depends on the scenario - I go for about 1 second (3) Execute ajax on blur, or on loosing focus, not on every keypress, (4) Implement a check in your ajax handler that ensures the request comes from the expected page (ie: not some random script a hacker wrote). (5) ONLY make the AJAX call when some other basic validation of the form element has taken place [ie: the basic javascript validation]
I hope this helps. Form validation using ajax is absolutely nothing like being even remotely similar to javascript validation. It is an interface into your database, and you need to be carefull with it.
It helps to imagine how you would hack into your own site - knowing which email addresses are registered with your site is a great place to start. So I could write a script to generate random email addresses using common words and/or names and hammer your ajax handler to obtain a list of registered email addresses to your site. I could do this quickly IF you didn't follow the advice (1)-(5) I stated above.
Once I have the emails, I just google them ... chances are that gives me a name. I can guess the username from there. So now I have username and emails. Passwords would take too long to explain, but if I can get the usernames or emails that easily ... it marks you out as a target and you will get more attention that you really want.
Im working on a registration validation system at the moment - Id be happy to share it with you if you'd like. Probably I'm missing something important !
Peace out.
I'm working in CodeIgniter, and I want to send requests to my controller/model that have several parameters involved. Is there a difference between passing those parameters via a hidden form (i.e. using $_POST) as opposed to passing them through URIs (e.g. 'travel/$month/$day/')? Are there any security concerns with this approach?
Example Security Concern:
URIs
http://www.example.com/travel/$month/$day/
Hidden Form:
form_hidden('month',$month);
form_hidden('day',$day);
Rule of thumb — GET requests should never change the state of things. So, if you actually change something or request — use hidden forms with nonce values (to prevent accidental resubmissions and CSRF attacks). Otherwise, there's no difference.
Auth should be decoupled from URIs and POST data — there are cookies, HTTP auth and SSL client certificates. Everyone knows that there is a 11th June in 2009, and a lot of people may know that you use /$year/$month/$day/ scheme in URIs (or "year","month" and "day" POST fields) on your site. But only those who are entitled to access should be able to see what's on this page (or POST data to this URI). And, yes, both GET and POST data can be easily tampered, so you obviously have to check for validity.
If you choose URIs, if the user bookmarks the URLs,
it brings security problem.
and if any user clicks any links ,
then the target web server can now know
HTTP_REFFER, and the server administrator
can know the link.
it means he can see the URI.
so my personal opinion is that
you better choose hidden form.
If you monitor your incoming-data (users are evil goblins, remember), and clean when necessary it's not going to make much of a difference. The difference only comes down to usability: if you want users to be able to access the same results without always having to go through a form, then use the URL method.
In all honesty, your example doesn't given enough data to determine which method (POST/GET) would be appropriate for you.
Suggested Reading: GET versus POST in terms of security?
I ran into this same issue recently. When anything additional is exposed in the URL, you run the risk of exposing website methods/data. After quite a bit of research, I elected to only show variables when absolutely needed or if the page was just a simple view. The more data you expose in your URL, the more checks you'll likely need to put in place (what if the user modifies the URL in x way).
Another consideration is the ability to bookmark or link to URLs (presumably views). One idea is to hide variables in the URL via an encrypted string. You could then store the encrypted string in your database and serialize as needed. I did this for a search engine and it gave me the best of both worlds. This was with CodeIgniter.