Tag Info

New answers tagged

0

While it's been alluded to in the comments above, it might be useful to note that one reason "Information such as operating system, web server version, PHP version and more. Some stack traces may contain system/environment variables that should not be made public!" (See comment above by @Alasjo and @Danny Beckett) is bad, is because knowing the software ...


10

There are two issues here, and the OP asks about the less important issue. Showing the trace This is the issue that the OP asks about. There are debates regarding how much of an issue showing a trace is in general, and this particular example displays nicely that displaying a trace can be a security issue. The reason for that is that it lets us (you, me, ...


2

Port 443 is the default port for HTTPS communication using SSL/TLS. As such, if you can reject and/or redirect traffic on port 80 (the default unsecured HTTP port) and reject all other ports, and if you can trust your web server OS's TCP/IP and TLS implementations, this scheme is as safe as any publicly-accessible computer communications endpoint can be ...


2

TL;DR Yes, if done properly, the system you've designed should provide a small security gain, but it probably isn't the best option. The expanded version: When we design security into a system, we first develop a threat model, and then we figure out how our system is going to mitigate those specific threats. So, the question for you is: "What is the ...


2

I am going to answer your question with a barrage of other questions. Well does your app actually need to hit the open internet ? or can it simply exist on a company intranet? The majority of 'java exploits' are simply ways that java's sandbox can get broken out of and of little consequence to legitimate java applications since it is really a apples and ...


6

Notice that stack traces include parameters. If there are function calls that pass in passwords as arguments, those will end up in stack traces. It's obviously a disaster if one user can cause the password of another to be displayed back at him. Less obviously, user passwords are now sitting in log files; which will make your users very mad. At the ...


21

There are two different aspects to this: Is the bug causing the stack trace a security vulnerability. Is the framework configured to show stack traces to outsiders. The error message Invalid Character Error sounds a lot like forgotten escaping, which can very often be exploited in some way. So you should be concerned about the stack trace because it is a ...


3

In your example, the people can see the structure of your directories which they could use for potential attacks. You'd be surprised how much a 'hacker' can do with very little information. So Yes in general it's a big problem in terms of security. Like Alasjo is saying, it's also not user friendly and an error page is a good alternative. For example in ...


0

An offline/local encryption/hashing server. Imagine this an user register himself >on the website but instead of the current site hashing and storing the password. This exposes the password to a unknown server, with unknown security for the password itself. Its better to NEVER send an password over the wire at all. you could use a java script hashing ...


57

On production (contrary to development) environments, stack traces and error messages should be logged to file instead of dumped on screen. This is because an attacker may learn things about your system that could help compromise your system. Information such as operating system, web server version, PHP version and more. Some stack traces may contain ...


1

RCP and RAP applications are typically built using the Eclipse E4 Tool package. There may be test cases unique to the target underlying operating system -- Eclipse runs on OS X, Linux, Windows, and a few other OSes. First, get the Delta Pack -- http://download.eclipse.org/eclipse/downloads/drops4/R-4.4.2-201502041700/#DeltaPack The Delta Pack contains all ...


0

No, being able to submit an empty form is not a vulnerability. But if this happens due to the lack of front/back-end validation, then the form is vulnerable to many other forms of attacks such as XSS and injection. An empty submission is not much different to a proper submission when it comes to DOS. In a proper submission, you may have additional processing ...


1

Unless you have explicitly expressed consent from the owner of the website, you should never test the website for its vulnerabilities. In the US, this falls into Computer Fraud and Abuse laws. When you are trained in ethical hacking, you get the opportunity to learn such laws, so you could do your work ethically and lawfully. If you are new to security ...


0

For intrusion detection you will definitely want to monitor your access.log and error.log files for this web app. I would look out for: Unusually high traffic. Figure out what a normal amount of traffic is based on your access.log and set a monitor to alert you if you suddenly get a much greater amount (e.g. 10 times more requests) that could indicate ...


4

Your question is highly dependant on your jurisdiction and the jurisdiction of the server. But, in many jurisdictions, what you have described is "unauthorized access" and would be considered illegal/against terms of service/unethical. As for your specific liability, you would need to ask a legal professional in your jurisdiction.


3

If you are allowing shell commands to be executed from the browser, then what you are effectively doing is allowing the user to log-in and execute commands on your system as the user that the web-server is running as. Ask yourself if that is what you want to do? The answer is definitely no. No-way. No, not never. In fact, hackers spend a lot of time trying ...


4

The problem is that there are a whole load of ways to get XSS in such a case: <style src="http://ha.ckers.org/xss.css"/> <a onclick=alert(1) style="position:absolute; display:block; z-index: 9999; top:0; left:0; width:10000px; height: 10000px"></a> <div onmouseover='alert(1)'/> <svg src=x onerror='eval("...")' /> Just to name ...


1

Web browsers evolve constantly. It is possible (although very rare according to my experience) that you manage to create a blacklist that blocks every meaningful XSS attack today, but tomorrow a new browser feature may introduce new possibilities for the attacker. You can check out http://html5sec.org/#html5 to see how many weird just got introduced ...


2

The main thing your enabling that is a problem is your opening your shell to subshells. e.a. just executing a command like /bin/bash would allow an attacker to gain access to your server. If you really wanna keep running a service like this i would suggest you limit the options the end users (and an attacker) can use, by only allowing commands you know are ...


0

No, because SQL Injection and Insecure Direct Object References includes the case of 'ability to run SQL that the user has access to but the application was designed to not allow'. Your method will limit the ability to get at stuff outside their permissions, but in most cases that includes things that aren't intended to be open, as well as system ...


1

Not effectively, no. You're always going to have cases where row-level security can't properly emulate the business processes. You'd also need to have a lot of "general purpose" accounts for things like user signup. The whole thing would be convoluted, difficult to maintain, and largely ineffective. Keep in mind, also, that SQL injection potentially does ...


0

if you're still confused by the second example and want to think of a non-URL attack then imagine a website user is asked for secondary authentication but is already authenticated (as in a bank website when you are often asked to enter your password again to authorised a transfer). The person asks for an action to complete (like the bank transfer example) ...


4

Both cases are serious vulnerabilities, and the security approach is wrong. First of all, the form itself shouldn't escape anything. You might want to check the input, but you do not manipulate it. Escaping is done in a specific context like a database query, not globally. No, it's not secure to simply prepend a backslash to single quotes in the ...


3

OWASP offers some solid advice on their site: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet You'll be safer and better off using a well-respected resource than inventing your own solution through trial and error. However, learning how an attacker works through experimentation like you're doing, is one of the best ways of learning ...


4

"Average length of time that an announced vulnerability has widespread exploitation", T "Attractiveness of server as a target", A, on a qualitative scale of 1-5 (higher number representing more attractiveness). "Ease of exploitation", E, using the CVE score as a basis of common comparison (T/A) x E = N Considering that T is now considered to be measured ...


1

In most cases, what seems like the best way to handle this is to use the functionality provided by your OS to store credentials and password. On OSX and iOS, you can use keychain. Under Windows, you can use the credential manager (also called password vault), DPAPI or the certificate store, depending on what exactly you want to do. In any case, I suggest ...


1

I doubt that it is possible to add custom cipher suites to Chrome or Firefox and to keep these maintained with all the rapid updates. I don't know about adding ciphers to the Windows system so that they can be used by IE, but given that even Microsoft itself has serious problems in this area I doubt that you can easily add ciphers there and keep them cheaply ...


1

There are a couple of advantages. If your host sits behind a reverse proxy, you are implementing the "defence in depth" model. Let's say your web server has an exploitable vulnerability which you have not patched yet. If your web server was directly accessible without being behind a reverse proxy, your host's vulnerability can be exploited, resulting in ...


0

If you want to separate or distinguish GET/POST actions, you should use AcceptVerbs attribute. For example, to force an action to only respond to POST requests, add the following attribute to it: [AcceptVerbs(HttpVerbs.Post)] And also add the following to the GET one [AcceptVerbs(HttpVerbs.Get)] By doing this, you can ensure that only desirable request ...


0

Can't deduce much from your question but if you are responsible for code repository structure then I'd recommend you differentiate config repository and code repository. Where Code repository would have the actual code & config repository would held these secret keys. If I were you, I'd also ensure these secret keys are not stored in plain text and ...


0

If you can't perform any change to website A, you cannot achieve what you need... However, if you can change website a or add a new page, module, method or any server-side thing, Digital Signature algorithms are designed to do similar works. An example is in the following... In site A, encrypt a time stamp first with private key of A and then encrypt it ...


1

Full disclosure: I'm the "inventor" of visualCaptcha. First of all, I love seeing so much people interested and using visualCaptcha. It's been getting a lot of attention and love in the past 6 months. It's amazing to see more and more people using it and interested in improving and "cracking it". I do want everyone to understand the problem visualCaptcha ...


1

All one would need to do is split the captcha into individual images and perform a Google image search of each image and the target word. And simply pick whichever one has the most results .From that point I am fairly sure that one could get pretty damn high accuracy. You can do a search for "Type below the answer to what you hear" OBJECT where OBJECT ...


3

No - I would't not consider the ability to submit an empty form as a security vulnerability. I can't think of a reason that the ability to submit an empty form would be more vulnerable than the ability to submit a form with valid or even dummy data. It is an indication of a poorly written application - and if I came across this I would suspect that there ...


0

The system you're describing sounds a lot like standard cookie based authentication/session management systems, in that you authenticate the user and then provide a session token to them which allows you to identify requests from that user for the duration of their session. Whilst you could implement this manually, I would recommend against it, as there are ...


2

To try it out, I've written a small bot that tries to post the the visual captcha demo. If first initiates the captcha session, telling is only wants 2 options using http://demo.visualcaptcha.net/start/2. Than it picks one of the two possible results and posts to http://demo.visualcaptcha.net/try. Result: ✓☓☓✓✓✓☓☓☓☓☓☓☓✓✓☓☓☓☓☓✓☓✓✓☓✓✓☓✓✓☓✓✓✓✓✓☓✓☓✓✓✓☓✓☓✓☓✓✓✓ ...


5

There are two considerable weaknesses in the live demo which make it quite trivial to break: There are only 5 possible answers to the captcha question, so a bot has a 20% chance to solve the captcha by picking a random symbol. The demo didn't ban me after picking a wrong answer over 20 times in a row, so there is no reason why a bot can't just keep ...


1

An old question, but adding an answer for modern times. For sensitive responses, you should set the following header: Cache-Control: no-store, must-revalidate These days, you probably don't need to worry about the HTTP 1.0 Expires header. Pragma is only for requests, not responses. To refresh the page just after session timeout (so that the login form ...


1

To me it sounds like IDOR, Insecure Direct Object Reference, which OWASP defines as, "Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or ...


1

I think it is fine to have a web facing panel as long as: Its not guessable, for example, www.example.com/admin. U don't want notorious users to attempt brute-forcing for two reasons: Incase the brute-force succeeds. If u have an account lockout policy in place, which you should, u don't want to be locked out by notorious users. Use strong passwords ...


0

For low value sites, username and password is ok. There are a lot of sites that are just not worth hacking into, and where the risk/cost of compromise to you is fairly minimal compared to the cost of securing it. For most sites though, you should require the use of HTTPS or VPN when doing administrative functions. There are now some SSL certificate ...


2

It depends if you're going to get a budget or not to do this. Welcome to the world of IDS/IPS and SIEMs. My favorite tool that I used as an intern, and still use is OSSEC HIDS (Open Source Security Host-Based Intrusion Detection System). It's a really sweet open source tool if you only need a small cluster of hosts monitored and don't have the funds to ...


0

Lot of applications relies on a simple username/password combination. This is not the technique that you should worry about, but how you implement it. You need to make sure that passwords are strong enough not to be guessed. They should not be stored in plain-text in your database in case it gets compromised. Furthermore, you want to avoid interception of ...


5

...sounds to me like Improper Access Control. From CWE-284: Description Summary The software does not restrict or incorrectly restricts access to a resource from an unauthorized actor. Extended Description Access control involves the use of several protection mechanisms such as authentication (proving the identity of an actor) authorization ...


3

I always use the Web Application Security Consortium classification. You may use it to classify the threat regarding two of its aspects: Attack (the method used to achieve the result) and Weakness (the flaw that was exploited by the attack) Using that classification, the attack should be categorized as Abuse of Functionality (as you are entitled to ...


1

Identity Masquerade. However, I feel that the method -- not the damage -- should be named. Therefore, I would simply refer to this as an authentication bypass.


1

Technically feasible? Certainly. It doesn't sound different from any other live CD, just with a server-oriented environment rather than the more traditional desktop-oriented one. What advantages do you picture this having, though?


0

Yes, it appears optional. According to http://daniel.haxx.se/blog/2015/03/06/tls-in-http2/, it was originally part of the HTTP/2 specification, but was later moved into its own spec as an extension of HTTP/2, http://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-06. It would appear that it was finally implemented in Mozilla in late 2014, and was finally ...


0

If website A and B are linked internally, you could just transport the session information, so the session key can be used to automatically login to website B - doing this without website A and B communicating internally somehow would very very difficult to secure. Basically you need a method of A telling B which client session codes are valid, without ...


3

What is one of the best ways to determine whether or not a user is abusing IPs? There's no good way, and it probably shouldn't be your goal. The fact that you've been "tracking actively-used IP addresses for each user" means that you already have a tracking mechanism better than IP addresses that you should use instead. As we've been tracking ...



Top 50 recent answers are included