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.
I have a Bolt Authentication issue that I don't know how to solve. I restored a backup from my online provider to my local machine. I can launch the browser and run "CALL db.schema" and the query returns. But when i try to just select a sample set of data I'm seeing this in the logs and the query never returns.
2018-06-25 14:39:23.778+0000 ERROR Unexpected error detected in bolt session 'ace2d3fffe92e75d-0005b714-00000004-4c1990029792d052-f94315d8'. The client is unauthorized due to authentication failure.
org.neo4j.bolt.v1.runtime.BoltConnectionFatality: The client is unauthorized due to authentication failure.
at org.neo4j.bolt.v1.runtime.BoltStateMachine.handleFailure(BoltStateMachine.java:742)
at org.neo4j.bolt.v1.runtime.BoltStateMachine.handleFailure(BoltStateMachine.java:728)
at org.neo4j.bolt.v1.runtime.BoltStateMachine.access$500(BoltStateMachine.java:62)
at org.neo4j.bolt.v1.runtime.BoltStateMachine$State$1.init(BoltStateMachine.java:435)
at org.neo4j.bolt.v1.runtime.BoltStateMachine.init(BoltStateMachine.java:145)
at org.neo4j.bolt.v1.messaging.BoltMessageRouter.lambda$onInit$0(BoltMessageRouter.java:70)
at org.neo4j.bolt.runtime.MetricsReportingBoltConnection.lambda$enqueue$0(MetricsReportingBoltConnection.java:69)
at org.neo4j.bolt.runtime.DefaultBoltConnection.processNextBatch(DefaultBoltConnection.java:195)
at org.neo4j.bolt.runtime.MetricsReportingBoltConnection.processNextBatch(MetricsReportingBoltConnection.java:87)
at org.neo4j.bolt.runtime.DefaultBoltConnection.processNextBatch(DefaultBoltConnection.java:143)
at org.neo4j.bolt.runtime.ExecutorBoltScheduler.executeBatch(ExecutorBoltScheduler.java:170)
at org.neo4j.bolt.runtime.ExecutorBoltScheduler.lambda$scheduleBatchOrHandleError$2(ExecutorBoltScheduler.java:153)
at java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1590)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
In my config file I can turn off security: dbms.security.auth_enabled=false and things will work. But I'd like to understand why/how I'm getting this error so I don't have to do that. In the administration tab of the desktop I've tried changing the password and it says it's successful but the error still remains?
Restoring to an identical version resolves issue. So good knowledge to have, back ups must be restored to identical versions. Or at least v3.3.5 restored to 3.4 will present this issue.
I have been playing around with authentication-flows and noticed that when I restart the web server the URL's no longer work, they are all invalid. I walked through debugging but I am still a bit lost as to exactly why, though I have a lot of good reasons why it should happen (and I am sure you do also).
I want to make a service which will be distributed to multiple containers and when a request comes in any of them could serve it. As the solution stands right now, it looks like I will have to make modifications to make possible.
What exactly is making the URL invalid? and what changes could I make to make my proposed solution possible?
Thank you in advance.
In response to Ohard's comment:
1. Why the URL is invalid
Let me tell you how I get the error. I deploy the war, submit forgot password. Receive the email to reset my password then stop the war. When that happens my reset password page extracts the enc. I then stop and redeploy the war. After isend a rest request with the enc and a new password to the /rest/setNewPassword mapping, then receive:
09 Jan 2016 03:50:48,799 [http-nio-8082-exec-1] ERROR
web.rest.UserActionRestController - Failed to decrypt URL content
aX8uaOWkqAUQN2xOzlPAOHJjPZaxBwho7.yoMeUtMnJA
in ohadr\crypto\service\CryptoService.java there is an exception on line 261:
throw new CryptoException("Failed to decrypt URL content " +
based64EncryptedContent, e);
which I then use a break point to find:
java aes javax.crypto.BadPaddingException: Given final block not
properly padded
I am sure if you try to reproduce this issue, you will find the same results...
Note: when I do this without the re-deploy everything works great!
2. How to make auth-flows work as SaaS
There are three use cases I want this service to fulfil:
Currently, If I host a service and it goes down without a fail-over, people who have URL's will be unable to use their links when it comes back up. I want them to be able to use the links regardless.
(untested -- but will be soon) Similar to the second, If I host this service on multiple docker containers I believe that it will not be able to receive link that did not orginially come from its container, therefore containers could not share unsorted loads. It should be able to read any of the enc's and process it.
EDIT:
1. Why the URL is invalid
An even easier way to test this is just to submit a forgotten password, get the email and then stop the war. Redeploy it, then click the link. I got this stack trace:
https://drive.google.com/file/d/0Bwa-JXbjFUDueXVMWWJibjY2Zm8/view?usp=sharing
Don't worry about csrf it is not enabled.
1. Why the URL is invalid
As it looks like, the ICryptoUtil instance is re-created after you redoply the war.
CryptoService.java line 38:
return ContextLoader.getCurrentWebApplicationContext().getBean(ICryptoUtil.class);
I suggest for you to do a small test. Encrypt a string twice, now and after the redeploy and compare the results.
If you got 2 different results then your crypto is not capable to decrypt an encrypted string of another crypto instance.
#EdiZ is right.
To be more accurate, every time your web-app loads, Spring loads all the beans. Among them are Crypto's library beans, such as CryptoUtil and CryptoProvider, and if you look carefully you will notice on DefaultCryptoProvider.loadMasterKeys() that a new key is generated.
I believe that explains the behavior you see.
Currently, If I host a service and it goes down without a fail-over,
people who have URL's will be unable to use their links when it comes
back up. I want them to be able to use the links regardless
It seems to be a duplication of your first question; I think that the first issue will have to be resolved in order to make it work as you wish. If the server reboots, all the links become invalid - the users will have to click again on "forget password" (for example) and get a new link - it is for you to decide how big this deal is.
If I host this service and I do have a failover I assume the failover
will not be able to read URL that is not from it originally. It should
be able to read any of the enc's and process it.
I assume that you have to develop some more persistence, so the server can decrypt URLs that were not generated by it...
Hope that helps.
How can I handle unexpected errors in my Express app to avoid downtime?
My first thought was to use try/catch statements to handle unexpected error, but that only works with synchronous code. I found that one possible option was to use Node.js's 'Domain Module', however, it turns out, that it is deprecated, and will remain deprecated.
Currently I am handling errors, by using middle-ware that is provided by the express generator. I am also using a process monitoring program called forever. Is the process-monitoring and Express's middle-ware enough to for successful unexpected error handling, or are there other options that I should be considering?
To answer you bluntly, you cannot handle your unexpected errors. This is not to say you can not handle errors, obviously you can, should and must. What I am saying is if an error is handled, then the program expected it, and it is not unexpected, if the program did not expect it then it is unexpected, so essentially if you do handle the unexpected errors, your not handling unexpected errors, your just handling errors.
As developers it is our job to thoroughly element unexpected errors as best we can, though none of us will ever succeed completely. Through devotion, and rigorous effort, a level can be achieved where the unexpected errors in your code that do occur are very minimal, and the situation is tolerable, at least to a certain degree. Error handling is a process that will often continue long after a beta version release, and even long after the first real production release. As data is collected, in a way I will soon talk about, bugs/errors are found and eliminated through versioning & patching, techniques designed to continue increasing the integrity of software even long after it has been released.
As you should already understand, there is not one single fix that will take care of all your unexpected errors. You as a developer should rid your app of all programmatic errors before production, and handle operational errors as best you can, which means you should understand what a Programmatic error, and operational error is.
#1. Programmatic-Errors: errors and/or bugs within the code itself.
#2. Operational-Errors - "Errors that occur in areas that are outside of the control of the programmer. Errors caused be the client, by the network, by the V8-Engine(this can be Programmatic too though).
There is no clear cut way to define every error as either operational or programmatic, and grey areas do exist. There are ways of looking at the errors in question that can help make a definitive determination. If you look at your code and figure that you couldn't solve the error, by writing different code, or more code, its likely not a programmatic error. If your getting errors trying to connect to a particular host, and your connecting everywhere else just fine, it is likely operational. Operational errors occur, even when the code of the application is written flawlessly, just make sure your correct in your determination of your codes integrity.
Here is a couple examples:
OPERATIONAL ERRORS
Socket Drops
Request timeout
Failed to authenticate client credentials
Any errors caused by legality issues
Here is a couple examples:
PROGRAMMATIC ERRORS
Invalid type-of variable passed into a function
Incorrect/Invalid Syntax
Failed to authenticate client credentials
Name clashing
As I already pointed out, the purpose of understanding these two error types, is so you as a developer can eliminate all the errors, that you are not only responsible for eliminating, but you need to eliminate in order to have a half decent working application. In the world of Node.js Application Development, this is the part that separates The Hero from the Zero, the Women from the girls, Glorious Chihuahuas from Sasquatch (Okay I am bias towards chihuahuas) You get the Idea.
This is really not a Question or Topic that can be answered in a one liner, mainly because, you can't just handle all unexpected errors with some 3rd party NPM API, but also because learning, and knowing what to do is not a matter of learning more JavaScript syntax, but instead learning a paradigm that every developer who wants to build solid, well built Node.js applications needs to know.
I know some of you are talking smack right now, thinking you have the answer and it is so simple. Well its not. Those of you who are using, the event listener that catches uncaught/unexpected errors are not putting great applications into production, if any applications. I sure hope any company you work for doesn't let you put out code that uses it. For those who don't know what I am talking about it bellow this text block. FYI, its already been suggested on this page, which blows me away.
//Catch uncaught exceptions
process.on('uncaughtException', function (err) {
// handle the error safely
console.log(err);
});
ABOVE IS THE PERFECT EXAMPLE OF WHAT NOT TO DO!!!!!!
If an error occurs unexpectedly the right thing to do is throw it as an Error Object. Not doing this threatens the integrity of your entire application. Remember you will be away from your server when clients have to deal with the results of your failure to do what you were told was the right thing to do. Using the above code snippet threatens the Security of your server. This includes the information needed to access your server, your pem keys, your passwords, all your databases and databases data, and worst of all any client info you store including any credit cards and passwords you keep (make sure you Blow-fish that kind of stuff). Every thing is put at risk the minute you launch an app that handles unexpected errors this way.
possible issues include:
Memory references, that are used and passed around on the V-8 c++ level, can potentially get majorly screwed up. This could result in massive memory leaks. You may end up without the necessary memory to fulfill requests, or do anything for that matter. Memory leaks are a major topic right now in the node community, as developers are having a heck of a time debugging them.
Some transactions can get left open, especially during memory leaks, and the wrong request and data can get sent to the wrong users. Random people can wind up getting sent the session ID's of other people. This is something hackers will quickly take advantage of, especially if there's any finances involved.
There are actually several more, and memory leaking is a big problem despite making it worse to try to make another problem better. You can make both better, you as a developer just need to have integrity, thus your app will have integrity.
The reason that event even occurs is for logging and monitoring. It is actually implemented by default in each node instance ran, and is part of how Error objects manage to inform you of, and about, unexpected errors. Below is the correct way to use it.
process.on('uncaughtExceptionMonitor', (err, origin) => {
MyMonitoringTool.logSync(err, origin);
// if needed pass the error to a function that will throw it...
});
The above is an example from the Node.js website, where you can read further about error handling, and unexpected errors.
Node.js Official Error Handling Documentation
Lastly we talking about Error monitors. For small applications, error monitors maybe all you need in order to do a satisfactory job. The only way to know if you have done enough for errors & unexpected errors to go production, is to get to the point where you feel you have error handling for all your operational errors, and your programmatic errors have all been corrected. Then you need a logging system that logs your errors. You can build your own logging system or purchase one for a regular fee. You will need a monitor, again you could technically build one, and for most stuff I would suggest trying, but for this I would pay a very small monthly fee, and it will restart your application if it crashes due to unexpected errors.
The answers above were really bad, but this has some good stuff in it. I did get help from the Node site that I liked to above. I also got help from here, a resource I have referenced time and time again, you should too.Handling Unexpected errors in Node Applications
I would recommend pm2 over forever as it has several great features. We use it in our production website and it works great. Enable logging to track your exceptions.
http://pm2.keymetrics.io/
PM2 allows you to manage logs easily. You can display all application logs in real-time, flush them, and reload them. There are also different ways to configure how PM2 will handle your logs (separated in different files, merged, with timestamp...) without modifying anything in your code.
I have handled this in my application by listing to uncaught error on process in my "index.js".
//Catch uncaught exceptions
process.on('uncaughtException', function (err) {
// handle the error safely
console.log(err);
});
You can use try-catch using a combination of generators and promises. - https://gist.github.com/swarajgiri/16202e32aa4d80d45c62
On catching an error, pass it to an error handler, in your server/app.js.
// errors handler.
app.use(function (err, req, res, next) {
if (! err) {
return next();
}
res.status(500);
res.send('500: Internal server error');
});
You will still need to have either forever or pm2 manage it.
We are using a custom database data store in OpenAM. This store authenticates user against our Oracle database.
Now, there are many possible causes why that authentication might fail. The account could be locked in Oracle or the password might be expired.
The datastore catches the SQLException, but how do I propagate the cause to the OpenAM UI?
I can throw a AuthLoginException from authenticate(), but on its way to the AMLoginContext, it gets wrapped and AMLoginContext kind of ignores error codes of AuthLoginExceptionS anyway. Meaning: AMLoginContext doesn't read the error code from the exception but tries to determine the error code itself, and usually it just puts AMAuthErrorCode.AUTH_LOGIN_FAILED into the login state.
How do I get the UI to show the cause of the login problem?
As Bernhard says, that is not recommended. However, from your data store you could obtain a Debug instance (com.sun.identity.shared.debug.Debug) and you can log exceptions, and they will appear in [AM_INSTALL_DIR]/openam/debug.
edit: You can find examples of doing so throughout the OpenAM source code.