Hot answers tagged web-application
42
Think about it this way
On one hand, there's nothing wrong with it. If your application is secure enough against SQL Injection, then an attacker won't be able to do much with that information. Unless you're naming your tables table_2231 and your columns column_4231 (in which case I hate you), it's not gonna be difficult to guess your tables names anyway. ...
29
Easier to hack? No. Easier to DoS? Potentially. Using an IP address instead of a host name with a DNS entry means you're giving up a layer of routing flexibility that can be very beneficial.
For example, if malware targets your IP address in a DoS attack, if you're using a domain name, you switch the IP address of the site and in the DNS record, and ...
14
You've come to the right place. Welcome to IT security!
is there any sql injection for this code?
Yes
if there is what is that Entry?
username: [any username from your website]" /*
password: sux0r")*/ OR ("1"="1
It will run this query:
SELECT * FROM `config`
WHERE `config_admin_username`="[any username from your website]" /*
AND ...
12
Typically if your site is accessible as http://1.2.3.4/ that would imply that it is not enforcing any limitations on the Host: header. That would mean that you could access it not just through IP address, but any hostname that happened to resolve to that address - including a domain an attacker registered and pointed at it.
This opens up DNS rebinding ...
12
Get a known clean version of your site and identify the differences between the known good code the and current (hacked) production code. Study how the changes may have been made and repair.
Update the passwords.
Fix the FTP certificate issue - consider using 2 factor authentication.
Find a way to scan your code for vulnerabilities - peer review or ...
12
If the only user on the database that can change records is root and your CMS uses the root user to perform queries then you have a problem. Your root user should never be used by a website.
Get a limited user which can only access the tables and records he needs to access restricted with the right permissions. If he doesn't need delete or update, then ...
11
Exposing table names might have broader consequences than you expect. For instance you could be putting your company at legal disadvantage by disclosing a table names like "deleted_messages", "profile_views", "single_female_users" etc. Retention of that data and user privacy suddenly becomes a topic of discussion and can cost much.
You cannot always control ...
11
I don't understand how these database tables are accessed. Surely it is not SQL Injection, as that should be a thing of the past with prepared statements,
Ahhh assumptions.. Have you seen the OWASP Top Ten project? SQL injections have always been a constant source of security issues.
I cannot see how changing any session state would effect the ...
10
It depends on the context the injection happens.
Obviously, if the injection happens in the context of an elements content like this one:
<p>Your search for "❌" has returned the following results:</p>
< is required to switch from text to markup. But even here, if you echo user input in a <script>, e.g.:
<script>var search = ...
6
Short answer: No.
Long answer: In a lot of cases, yes, but don't do it.
Someone correct me if I'm wrong about anything here.
If, and only if, the text is only outputted to "the body" of a standard styling element, and if that body isn't then grabbed by some Javascript or otherwise, then I would honestly have to say yes. By body I mean the text is being ...
6
TildalWave has a great answer, but there is a great mediation to SQL injection that was missing from the answer. Prepared Statements. As Tildal said the entire statement with user input is parsed with no parsable distinction between variables and constant parts of the statement. The solution is sending the constant part of the statement with variable ...
6
I think the operative word in the question is "afraid." The aversion is based on fear, not fact. The reality is, the threat model isn't particularly realistic. Commercial web software development companies nearly universally use JavaScript these days, obfuscated or otherwise, and I challenge you to find me even a single example of one that's had it's JS ...
6
The relevant practice you're describing is leeching and the immediate connotation is inappropriately as harsh as the term "junk bond".
Your conceptual description is accurate but YouTube's content is leechable, sites like HuLu, even CSpan go to greater lengths to protect their content by instructing your browser to cache the content in your systems RAM ...
6
If you have multiple websites on the same server then depending on the issue, a security problem with one site may well affect another.
Mitigating this essentially means increasing the separation between the two applications. You could do this by using somthing like a chroot jail or if that's not enough isolation you could look at using VM guests on the ...
5
See this question for a sense on how secure VMs really are. How secure are virtual machines really? False sense of security?
A good general rule is to not allow the VMs to communicate with each other through networking. This means proper measure to segregate network access should be enforced.
If you notice a compromise on any of the VMs, immediately nuke ...
4
What precaustions should be taken when the file displayed by a webpage is specified by the GET value
You should be sure to put additional filtering on it to make sure it doesn't try things like that. Personally, at a minimum, I would attempt to parse and reform the input and make sure that no operations like directory changes can occur.
A better option would be to store the filenames in a DB and pass in a simple token that could be used to look up the ...
4
Most of the OWASP top 10 still applies to web services. A more detailed resource would be the Mozilla WebAppSec Guide.
"RESTful" web services should not have a "session token". Related: "Do sessions really violate RESTfulness?" However at the end of the day you need a some kind of token for authentication purposes.
In short, if you are writing a ...
4
This is most likely a PHP LFI (Local File Inclusion) attack. The .php.jpg "photo" actually contains valid PHP code that is then parsed by some other script on your site which is vulnerable to LFI.
The other files you found were dropped post-exploitation after the LFI vulnerability was exploited.
You can post the boy.php.jpg for further analysis. Host it ...
4
Recommendations to management need to be framed in terms of effort, costs, and risks. 'Best Practices' and marketing-speak will not communicate well on their own, so defining the problem in terms of effort, costs, and risks will keep everyone focused on the realities of the situation.
Your 'outsider' is not helping the discussion with tossing around a ...
4
There are various levels of protection you can use. The most basic would be to configure them as separate sites running as different users and only allow each site's user access to the assets it needs. At a basic level, this should prevent one site from being able to access the other.
There are still some attacks that may be able to escape this though (if ...
3
I don't understand how these database tables are accessed. Surely it is not SQL Injection, as that should be a thing of the past with prepared statements,
SQL injection is a big issue for a site of any size. All it takes is one missing mysql_real_escape_string() and your program is compromised. As with most things in computer security, there are ...
3
Contrary to the other answers, I consider that using ip-addresses instead of hostnames is bad practice for a number of reasons. Most notably:
It is considerable harder for average users to verify that they are talking with the correct service and not with a phishing site: They have to remember a large number instead of a name.
Using ip-adresses implies ...
3
The easiest way is to use blind sql injection. You know if the question you are asking is right or wrong depending on how long the query takes to execute. This is also the most flexible approach because a blind sql injection exploit will work regardless of the type of sql injection being exploited (blind, non-blind, select, insert, update, delete....).
...
3
There is a good reason for preventing concurrent connections - if they are not needed by your users.
A good rule of thumb is to not allow more functionality than that which is needed. If your users are never going to connect more than one simultaneous session, disallowing it would reduce the risk of attack (as an attacker would not be able to conduct their ...
3
You should always assume that registration information is what your real user wants, any later change and the user should be notified, especially when it comes to critical information such as username and password.
When the email address is changed, an confirmation email should be sent to the new address containing a link to activate the new email address. ...
3
Yes there's a risk as this is a classic session fixation issue (OWASP Page). Standard good practice for web application session management would always be to re-issue a random session token whenever the user submits a login. Anything else (either not re-issuing on login or allowing user set session token values) is not a good idea.
How much of an issue ...
3
If your session ID is truly random, there is no additional security in AES-encrypting it. If, however, it is not random, I would strongly recommend against doing so, for reasons similar to why no-one sane uses predictable session ID tokens.
Also, if you're not using SSL, your traffic can be sniffed. This means that, no matter how much you encrypt the ...
3
It's a bad idea.
Encrypting the session identifier has no real impact on the security of your application. If the traffic is sent in plaintext (without SSL) anyone is able to read that encrypted session ID and then use it to impersonate the legitimate user.
Let's say my session ID is 12345. Every time I want to go to your house you ask me about my session ...
3
You seem to already know that obfuscation isn't actual protection, so I'm not gonna lecture you on security by obscurity.
What makes sense is this: Put your competitive code on the server to protect it, then obfuscate client-side code as much as you want. Granted, it won't give you much security but it'll definitely deter kiddies snooping around, and it'll ...
2
As a pentester being able to find the subdomains for a site comes up often. So I wrote a tool, SubBrute that does this quite well if I do say so my self. In short, this is better than other tools (fierce2) in that its a lot faster, more accurate and easier to work with. This tool comes with a list of real subdomains obtained from spidering the web. ...
Only top voted, non community-wiki answers of a minimum length are eligible
